Set WindowGlobalParent::IsInitialDocument correctly
Categories
(Core :: DOM: Content Processes, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox92 | --- | fixed |
People
(Reporter: nika, Assigned: nika)
References
(Blocks 1 open bug)
Details
Attachments
(4 files, 1 obsolete file)
I was looking at WindowGlobalParent
, and came across the mIsInitialDocument
field which was apparently added in bug 1543251. This appears to currently be set incorrectly. In order to fix this, I think we need to change a few things:
- This bit should be set on creation time for documents created with
WindowGlobalActor::AboutBlankInitializer
, as these windows are always initially for initial documents. - This bit must be cleared as soon as the initial
about:blank
document is replaced in the content process. Currently once the bit is set, it is never unset, even once another non-initial document has been loaded. (with the one exception being a call todocument.open()
). This should probably be done innsGlobalWindowInner::InnerSetNewDocument
. (In general we probably need aSetNewDocument
callback onWindowGlobalChild
to update various state. I'm a touch worried that the DocumentURI isn't being updated correctly in this case either, now that I'm seeing the code again).
Comment 1•5 years ago
|
||
The priority flag is not set for this bug.
:jimm, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•5 years ago
|
Updated•5 years ago
|
I can work on that, but what does "initial document" mean exactly?
Assignee | ||
Comment 3•4 years ago
|
||
When an <iframe> is created, it is possible to immediately access .contentDocument
, in which case you will see an empty about:blank
document. This is an initial about:blank document, which is replaced by the real document after it is loaded. We also create these when creating other toplevel browsing contexts, such as for window.open()
.
The interesting property of this type of document is that, when it is navigated to another same-origin document, that document shares the same Window
object as this about:blank document (for historical reasons).
So, it should be true
initially, then false
once we start loading a new document?
Assignee | ||
Comment 5•4 years ago
|
||
(In reply to David Teller [:Yoric] (please use "needinfo") from comment #4)
So, it should be
true
initially, thenfalse
once we start loading a new document?
Yes, but only for initial about:blank documents, such as those created with WindowGlobalActor::AboutBlankInitializer
.
Attaching a prototype. Is this what you had in mind?
Updated•4 years ago
|
Do we have any way to test this property?
Comment 11•4 years ago
|
||
Deferring to Fission Nightly (M6)
Nika provided review comments. Yoric is waiting for Nika to answer some follow-up questions.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 13•3 years ago
|
||
The main remaining issue here is just that we don't initialize this value to true
when creating the temporary dummy initial window actors which are created before the content process is initialized and we don't set the flag quite as early as it might be nice to. That being said, this field isn't used in very many places right now, and I think it's highly unlikely that we're going to run into any issues in the current use places, so I'm going to deprioritize this for now.
Putting in MVP so we can re-assess where it's used and how important the work is before we ship.
Comment 14•3 years ago
|
||
Putting in MVP so we can re-assess where it's used and how important the work is before we ship.
kmag says he found a few cases that are broken and should be fixed before Fission MVP.
Some cases:
DocumentLoadListener
Service Worker code
Comment 15•3 years ago
|
||
Nika says the fix will be tricky and is not a super-high priority unless it’s helpful for some other reason. DevTools wants something like this fix.
Assignee | ||
Comment 16•3 years ago
|
||
This makes sure to clear and set the value more consistently when replacing
documents within a WindowGlobal, and makes sure to include the relevant flag in
the initializer.
In addition, the place where the flag is set is moved ahead to happen before
the call to Embed
so that the information is ready before the window is
created.
Assignee | ||
Comment 17•3 years ago
|
||
Previously only the value in the parent process,
windowGlobalParent.isInitialDocument
, was exposed to chrome JS. for testing
and other purposes, it is also useful to be able to read this value from JS in
a child process.
Depends on D119815
Assignee | ||
Comment 18•3 years ago
|
||
This test is based on the test written by ochameau for
https://phabricator.services.mozilla.com/D118740, but with modifications
to specifically test isInitialDocument
.
Depends on D119816
Assignee | ||
Updated•3 years ago
|
Comment 19•3 years ago
|
||
Pushed by nlayzell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/615b15674468 Part 1: Ensure IsInitialDocument is set earlier and consistently on WindowGlobalParent, r=smaug https://hg.mozilla.org/integration/autoland/rev/38b111a76a73 Part 2: Expose Document.isInitialDocument to chrome JS, r=smaug https://hg.mozilla.org/integration/autoland/rev/3e6182be78c7 Part 3: Add a test for isInitialDocument, r=smaug
Comment 20•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/615b15674468
https://hg.mozilla.org/mozilla-central/rev/38b111a76a73
https://hg.mozilla.org/mozilla-central/rev/3e6182be78c7
Description
•