Ability to retrieve iframe's BrowsingContext

[Lightning00Blade]

When creating iframe an a Context (navigatable) is created, but there is no way get its id if you know the element, this is need for example if you need to execute a command on a specific iframe, or listen on it's events.
CDP exposes 2 ways of doing this.
During the navigation event (from about:blank to iframe.src) Page.frameNavigated, a property name that contains the iframe's name, id or null.
Using Handle and calling DOM.describeNode. Return has a frameId property.

[whimboo]

The browsingContext.Info type has a context field, which is a string and matches the id of the BrowsingContext.

[OrKoN]

I believe the issue is that it is not possible to know from a serialized iframe element what context it currently belongs to.

[juliandescottes]

So to summarize there's no issue with browsingContext.contextCreated, as you should get the context and parent fields for the new context which was created. The issue is that you want a way to link the serialized frame to the context which corresponds to its contentWindow?

[OrKoN]

That's right: basically the implementation for https://pptr.dev/api/puppeteer.elementhandle.contentframe/

[OrKoN]

Implementation: https://github.com/puppeteer/puppeteer/blob/main/packages/puppeteer-core/src/common/ElementHandle.ts#L252

[jgraham]

So in theory one can nearly implement this in script like callFunction((iframe) => iframe.contentWindow, arguments=[frame]). But the reason it doesn't quite work is that WindowProxyRemoteValue doesn't contain the context id for the browsing context (really navigable) containing the window. So I wonder if it would be enough to just give WindowProxyRemoteValue a value field with a context property containing that id (we could use sharedId for this, but that ends up erasing the difference between a browsing context and a navigable; we really want context to mean "navigable" and the sharedId on a WindowProxy should really change when the underlying object changes).

[OrKoN]

Adding context to the serialisation result of evaluating contentWindow would be sufficient, I believe. cc @sadym-chromium would it be feasible from the implementation perspective (I think it is another instance of the layering violation from Chromium's perspective)?

[whimboo]

I see. If we add such a value should we keep it in sync with the WindowProxy serialization in WebDriver classic? Probably yes.

[sadym-chromium]

Adding context to the serialisation result of evaluating contentWindow would be sufficient, I believe. cc @sadym-chromium would it be feasible from the implementation perspective (I think it is another instance of the layering violation from Chromium's perspective)?

let me check it out

[sadym-chromium]

Adding context to the serialisation result of evaluating contentWindow would be sufficient, I believe. cc @sadym-chromium would it be feasible from the implementation perspective (I think it is another instance of the layering violation from Chromium's perspective)?

As frameId is accessible from the DOM.describeNode, and accessible from the protocol inspector, I guess we can add the context value to the window.

[sadym-chromium]

Adding context to the serialisation result of evaluating contentWindow would be sufficient, I believe. cc @sadym-chromium would it be feasible from the implementation perspective (I think it is another instance of the layering violation from Chromium's perspective)?

demo of what it can look like: https://crrev.com/c/4613547

[jgraham]

I think this was resolved by #452

[OrKoN]

@whimboo and I found that the contentWindow can be null for certain types (I guess cross-origin isolated?) of iframes in Firefox. I think we overlooked this aspect when discussing this issue and perhaps we need to revisit.

https://html.spec.whatwg.org/multipage/document-sequences.html#content-window

[whimboo]

Specifically for Firefox you can see the restrictions in-place for cross-origin iframes here:
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#cross-origin_script_api_access

[jgraham]

But that doesn't say that contentWindow should be null. Do we have a non-WebDriver testcase (i.e. just HTML and JS)
where we get different contentWindow values in Chrome and Firefox?

[OrKoN]

@jgraham for example https://mathiasbynens.github.io/css-dbg-stories/iframe-navigations.html (Click append iframe with a cross-origin URL). It returns null in Firefox.

[whimboo]

@OrKoN are you sure? We are actually talking about the contentWindow and not contentDocument. The former one is present for me when I follow the steps from your last comment.

[OrKoN]

@whimboo you are totally right. I made a mistake in a hurry :( The contentWindow is not null but it seems to be being serialized as an "object" instead of a "window" in Firefox (thus, missing the context attribute).

[whimboo]

After some investigation I found that this is actually a bug in our BiDi implementation in Firefox. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1867667 to get this fixed. There doesn't seem to be anything needed spec wise as of this point.