Add `WindowContext`, a cross-process `BrowsingContext`-like object for per-window properties.
Categories
(Core :: DOM: Content Processes, enhancement, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox74 | --- | fixed |
People
(Reporter: nika, Assigned: farre)
References
Details
Attachments
(5 files)
This object would have synchronized fields, like BrowsingContext
, and would also hold the children list of BrowsingContext
objects. A BrowsingContext
would hold a list of WindowContext
objects rather than BrowsingContext
, and would have a currently active one.
The WindowGlobalParent
actor could likely inherit from WindowContext
, though the object will have to be separate from a WIndowGlobalChild
, and friends.
Navigations would involve replacing the WindowContext
.
(NOTE: I don't love the name, but can't come up with a better one off the top of my head - if you have suggestions feel free to ping me on irc)
Reporter | ||
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Reporter | ||
Comment 2•5 years ago
|
||
Reporter | ||
Comment 3•5 years ago
|
||
Transferring to :farre, as he's taking over finishing off this bug.
I've attached my WIP patch as of today to the bug, and also posted the split patch stack on GitHub at https://github.com/mystor/mozilla-central/tree/windowcontext, which is already split into parts.
Off of the top of my head the remaining pieces include:
- Fix the
CurrentWindowContext
system to generate coherent values in all processes, [1] - Expose the type through various C++ and JS-exposed methods,
- Testing & writing tests,
- More stuff I probably forgot...
In addition, in follow-ups, more work may be done to make WindowContext
participate more in BrowsingContext
's lifecycle, such as by holding the Browsing Context children list for a specific window.
[1]: I was considering doing this in a similar way to EmbedderWindowContext
by having a Browsing Context CurrentInnerWindowId
field which would be synchronized using the standard field-syncing logic, rather than the current custom behaviour. I believe this snapshot is part-way through experimenting with that change. I'm a bit worried about how it will interact with the EnsureSubscribed IPCInitializer logic, which may need to be replaced with an initial Transaction
object.
Comment 4•5 years ago
|
||
Andreas, do you have any progress updates or an ETA for this WindowContext object? It's blocking ETP support for Fission.
Comment 5•5 years ago
|
||
This is the top priority for Andreas right now and he already has patches that work (were WIP patches passed on from Nika) but he's currently debugging a race and a leak before those are ready for review.
Updated•5 years ago
|
Assignee | ||
Comment 7•5 years ago
|
||
N.B. Author is really "Nika Layzell <nika@thelayzells.com>". Change
before committing!
Assignee | ||
Comment 8•5 years ago
|
||
N.B. Author is really "Nika Layzell <nika@thelayzells.com>". Change
before committing!
Depends on D56741
Assignee | ||
Comment 9•5 years ago
|
||
N.B. Author is really "Nika Layzell <nika@thelayzells.com>". Change
before committing!
Depends on D56742
Updated•5 years ago
|
Comment 11•5 years ago
|
||
Pushed by afarre@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/418dc8150a3a Part 1: Introduce common SyncedContext logic, r=peterv https://hg.mozilla.org/integration/autoland/rev/641b9a29f6ee Part 2: BrowsingContext moved to SyncedContext, r=peterv https://hg.mozilla.org/integration/autoland/rev/3e750325953b Part 3: WindowContext using SyncedContext, r=peterv https://hg.mozilla.org/integration/autoland/rev/1738ac5ba848 Part 4: Skip setting autoplay status. r=peterv
Comment 12•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/418dc8150a3a
https://hg.mozilla.org/mozilla-central/rev/641b9a29f6ee
https://hg.mozilla.org/mozilla-central/rev/3e750325953b
https://hg.mozilla.org/mozilla-central/rev/1738ac5ba848
Comment 13•5 years ago
|
||
This causes the webreplay tests to fail permanently (tracked with the failure in bug 1580104). See also bug 1609815 about removing webreplay.
This change moved how the window global changes for CanonicalBrowsingContext
s. After this patch, what's the narrowest plate to put code in if I want, in the chrome process, recompute caches when CanonicalBrowsingContext
changes what content process it is connected to?
(In reply to Henri Sivonen (:hsivonen) from comment #14)
This change moved how the window global changes for
CanonicalBrowsingContext
s. After this patch, what's the narrowest plate to put code in if I want, in the chrome process, recompute caches whenCanonicalBrowsingContext
changes what content process it is connected to?
I'm going to assume this is assignments to mCurrentWindowContext
if XRE_IsParentProcess()
.
Comment 16•5 years ago
|
||
In the bug following intermittent failures (bug 1580104), there are 105 total failures in the last 7 days and seems like failures started spinking since the 19th of January. This is a tier2 failure, however, failure rate is high.
Andreas are there any updates on this?
Updated•4 years ago
|
Description
•