Enable access to the "opener" property within CanonicalBrowsingContext, even if the window was originally opened with "noopener"
Categories
(Core :: DOM: Core & HTML, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox129 | --- | fixed |
People
(Reporter: whimboo, Assigned: farre)
References
(Regressed 1 open bug)
Details
Attachments
(1 file)
For automation through WebDriver BiDi, we are seeking the capability to access the opener
property of a browser window or tab, even if it was initially opened with the noopener
attribute. This access should be restricted to privileged code running in the parent process, not accessible to any content JavaScript. The desired implementation would involve making this value retrievable via the CanonicalBrowsingContext
.
An example scenario is within Puppeteer, where the browsingContext.getTree
command from WebDriver BiDi is utilized to gather details about all open windows, tabs, and frames. In this context, having the ability to determine which specific window opened another window would be valuable.
Reporter | ||
Updated•6 months ago
|
Reporter | ||
Comment 1•5 months ago
|
||
Having such a property would be a big help for us to gain better support for Puppeteer.
Edgar, who would be an appropriate contact to provide further insights into the necessary steps for achieving this? Thanks
Comment 2•5 months ago
|
||
Perhaps we could reuse CanonicalBrowsingContext::GetCrossGroupOpenerID()
and expose it to chrome JS, https://searchfox.org/mozilla-central/rev/e69f323af80c357d287fb6314745e75c62eab92a/docshell/base/CanonicalBrowsingContext.h#92-96? :farre might know better.
Assignee | ||
Comment 3•5 months ago
|
||
This might work, the docs indicates that this is intended for downloads, so if we expand it's use we should make sure to also update docs and add tests.
Assignee | ||
Comment 4•4 months ago
|
||
Updated•4 months ago
|
Comment 6•4 months ago
|
||
bugherder |
Description
•