1837031 - Request for a unique id that references a browsing context (navigable) even after a replacement

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, enhancement)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

For our WebDriver implementation we need a unique id that references a Navigable and survives browsing context replacements. Given that we do not have Navigables implemented in Gecko yet (and as we have heard that there are no such plans), we would like to request a property on the BrowsingContext interface which could be used to reference a given top-level browsing context (tab) even if it has been replaced by a cross-origin navigation. This id would have to be available on the parent and the child process and if possible synced automatically. Would a name like navigableId make sense? Most likely we would also need a getFromNavigableId() method to retrieve the related browsing context.

Per WebDriver specification it needs to be a string but for easier handling inside Gecko it could be a counter internally. The only requirement would be that the values are unique.

As Olli pointed out CanonicalBrowsingContext::ReplacedBy gets called whenever a browsing context gets replaced. As such the known unique id could easily be set on the new browsing context, and should then automatically be synced with the content process.

Olli, is there something else that we haven't discussed yet? And how difficult would such an implementation be?

Thanks!

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Btw, why is https://searchfox.org/mozilla-central/rev/27e4816536c891d85d63695025f2549fd7976392/docshell/base/CanonicalBrowsingContext.cpp#314 not enough for this?

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

browserId wouldn't help us here because it would only allow us to reference a top-level browsing context and wont work with BrowsingContext.get(). Means we would have to differentiate between top-level and child browsing contexts. But with the information that we get with the command payload from clients - it's only an uuid - we do not know if that is a top-level or child browsing context. So we might have to check get() first and if no browsing context can be found using getCurrentTopByBrowserId() afterward. But this would only work if the browserId and id would never have the same value. Is that guaranteed?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

But the initial comment was talking about top level browsing contexts:
"we would like to request a property on the BrowsingContext interface which could be used to reference a given top-level browsing context (tab) even if it has been replaced by a cross-origin navigation."

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Yes, because only top-level browsing contexts are getting replaced. Also the summary of the bug still doesn't include that the requested unique id is for top-level browsing contexts only. So to be clear we need an id that is stable and can reference any kind of browsing context while the tab or a frame is alive.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/08 - 07/30) from comment #4)

Yes, because only top-level browsing contexts are getting replaced. Also the summary of the bug still doesn't include that the requested unique id is for top-level browsing contexts only. So to be clear we need an id that is stable and can reference any kind of browsing context while the tab or a frame is alive.

Olli, would something like that be possible? One thing I'm not sure about is how it would actually work for unloaded tabs.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

I'm still a bit confused why the current IDs we have aren't enough. There is browsing context ID, and there is browser ID.
Can't you store the information like
browserid + "-" + browsingcontextid ?

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #6)
Sorry for my very late reply here. This last reply totally got lost.

I'm still a bit confused why the current IDs we have aren't enough. There is browsing context ID, and there is browser ID.
Can't you store the information like
browserid + "-" + browsingcontextid ?

No this wont work due to different reasons:

1. WebDriver defines a window handle as a string, but using the above method might leak too much information to a WebDriver client so that it could guess the ids of other window handles and try to access those. We have restrictions for chrome scope but it would be good to prevent this. As such we are using a UUID for window handles.

2. The browsing context id changes for cross-origin navigations and as such generating an id in that format for a WebDriver client would mean it is invalid after a browsing context replacement. If a command specifies it, we are not able to correctly assign it to a browsing context anymore.

3. We want to have support for unloaded tabs in the future as well. As such having a browser id as part of the string wont work because it will be 0 (or null?) for each and every unloaded tab. And because there is no browser we also don't have a browsing context id.

Having a unique UUID coming from the platform and which never changes for a navigable (top-level) browsing context would be a great help for 1) and 2). For 3) we would still need a different method for sure.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Attachment: WIP: Bug 1837031, add navigable ID to browsing context

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

We seem to be fine without such a feature baked into Gecko. Especially when we have to rewrite the ids in the parent anyway to have them unique per WebDriver session. As such I'm going to close this bug now.