1583863 - (WindowContext) Add `WindowContext`, a cross-process `BrowsingContext`-like object for per-window properties.

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, enhancement, P1)

Description

[Nika Layzell [:nika] (ni? for response)]

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)

Comment 1

[2912vasant]

Updated

Comment 2

[Nika Layzell [:nika] (ni? for response)]

Attachment: Nika WIP (Nov. 4, 2019)

Comment 3

[Nika Layzell [:nika] (ni? for response)]

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:

1. Fix the CurrentWindowContext system to generate coherent values in all processes, [1]
2. Expose the type through various C++ and JS-exposed methods,
3. Testing & writing tests,
4. 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

[Chris Peterson [:cpeterson]]

Andreas, do you have any progress updates or an ETA for this WindowContext object? It's blocking ETP support for Fission.

Comment 5

[Neha Kochar [:neha]]

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.

Comment 7

[Andreas Farre [:farre]|pto Jul 8 -> Aug 2]

Attachment: Bug 1583863 - Part 1: Introduce common SyncedContext logic, r=peterv!

N.B. Author is really "Nika Layzell <[e-mail]>". Change
before committing!

Comment 8

[Andreas Farre [:farre]|pto Jul 8 -> Aug 2]

Attachment: Bug 1583863 - Part 2: BrowsingContext moved to SyncedContext, r=peterv!

N.B. Author is really "Nika Layzell <[e-mail]>". Change
before committing!

Depends on D56741

Comment 9

[Andreas Farre [:farre]|pto Jul 8 -> Aug 2]

Attachment: Bug 1583863 - Part 3: WindowContext using SyncedContext, r=peterv!

N.B. Author is really "Nika Layzell <[e-mail]>". Change
before committing!

Depends on D56742

Comment 10

[Andreas Farre [:farre]|pto Jul 8 -> Aug 2]

Attachment: Bug 1583863 - Part 4: Skip setting autoplay status. r=peterv!

Depends on D56743

Comment 11

[Pulsebot]

Pushed by [e-mail]:
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

[Daniel Varga [:dvarga]]

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

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

This causes the webreplay tests to fail permanently (tracked with the failure in bug 1580104). See also bug 1609815 about removing webreplay.

https://treeherder.mozilla.org/#/jobs?repo=autoland&searchStr=dt-wr&tochange=b634b7b787d55ebc15d59edfb6cbc3e9772563a6&fromchange=cae493b7ba5236f670fa4a25cbb51d361cfd14ce&selectedJob=285715109

Comment 14

[Henri Sivonen (:hsivonen)]

This change moved how the window global changes for CanonicalBrowsingContexts. 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?

Comment 15

[Henri Sivonen (:hsivonen)]

(In reply to Henri Sivonen (:hsivonen) from comment #14)

This change moved how the window global changes for CanonicalBrowsingContexts. 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?

I'm going to assume this is assignments to mCurrentWindowContext if XRE_IsParentProcess().

Comment 16

[Andreea Pavel [:apavel]]

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?