Closed Bug 1681973 Opened 4 years ago Closed 3 years ago

Identify top-level browsers using browserId instead of browsingContext's id

Categories

(Remote Protocol :: Marionette, task, P3)

Default
task

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1680479

People

(Reporter: jdescottes, Unassigned)

References

Details

(Whiteboard: [not-a-fission-bug])

Internally, marionette keeps track of currently open browsers. For instance, in driver.js there is the _browserIds map: https://searchfox.org/mozilla-central/search?path=&q=_browserIds which maps a browser permanentKey to the browsing context id.

However the browsing context id is not a stable id. When navigating across processes, browsing contexts will be swapped and the id will change. Instead for top level browser elements, we could use the browsingContext.browserId.

Since this id "leaks" to several helpers (in production code and test code), changing the logic will require to update all of them at once. See discussion at https://phabricator.services.mozilla.com/D98779#inline-559687

Henrik, is this bug related to Fission? Does it need to block shipping Fission MVP?

This bug blocks "Refactor registration of browsers" bug 1676671, which has a [marionette-fission-mvp] whiteboard tag.

Flags: needinfo?(hskupin)

It doesn't block our Fission implementation per se given that it was already a problem before. Also it doesn't block the browser registration, but depends on it. So no, it doesn't block Fission MVP.

Severity: -- → S3
Flags: needinfo?(hskupin)
Whiteboard: [fission-]

To reduce the risks for regressions lets do it when all the framescript code has been removed.

Depends on: 1669172

Not a Fission bug

Whiteboard: [fission-] → [not-a-fission-bug]

Actually this is a dupe of bug 1680479.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
No longer depends on: 1669172
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.