descendant documents of top OOP iframe document keeps inactive if the top OOP iframe document is initially invisible
Categories
(Core :: Layout, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox91 | --- | fixed |
People
(Reporter: hiro, Assigned: emilio)
References
(Regressed 1 open bug)
Details
Attachments
(3 files)
This is the reason why test_bug1451199-1.html (and test_bug1451199-2.html) sometimes timed out on fis-xorig runs.
So what's going on when the time out happens;
- in fis-xorig runs test_bug1451199-1.html document is loaded in an OOP
- and the iframe in the test_bug1451199-1.html document is also loaded in the same process of the test_bug1451199-1.html
- when the presshell for the test_bug1451199-1.html document gets initialized, SetIsActive is called with false since the BrowerChild is invisible at that moment
- same thing happens for the iframe's preshell, i.e. SetIsActive is called with false
- then after that, when the BrowserChild::MakeVisible gets called we do call PresShell::SetIsActive(true) for the test_bug1451199-1.html presshell
- but it doesn't descend down its child presshell (i.e. the iframe presshell)
- thus the iframe's presshell keeps inactive
- so even after the iframe's width changes, it doesn't call FlushPendingNotifications for the iframe's presshell since
mIsActive
check in WillPaint (Note that the WillPaint gets called from nsViewManager::ProcessPendintUpdates in nsRefreshDriver::Tick) - thus we never get media query change events for the iframe document
I am quite unsure what the active presshell means. If we don't have situation where an ancestor is inactive but a descendant is active, we should propagate it into descendants?
Assignee | ||
Comment 1•3 years ago
|
||
but it doesn't descend down its child presshell (i.e. the iframe presshell)
Yeah, that seems broken, we should probably:
- make
QueryIsActive
handle the subdocument case so that it computesfalse
properly (which right now wouldn't, IIUC). - Make
SetIsActive
callQueryIsActive
on in-process subdocuments.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
This moves the logic of whether a pres shell should be active to a
single place to make it sane to reason about, and fixes the
subdocument propagation when a BrowserChild becomes visible.
Assignee | ||
Comment 3•3 years ago
|
||
Reporter | ||
Comment 5•3 years ago
|
||
Thank you Emilio! (Though I didn't expect you to respond in your off. :)).
Comment 6•3 years ago
|
||
Backed out for causing Android failures.
Backout link: https://hg.mozilla.org/integration/autoland/rev/57427436cfd82390c961ac0b86b996cb9671c97d
Assignee | ||
Comment 7•3 years ago
|
||
GeckoView always calls preserveLayers(true) on all <browser> elements,
which causes the puppet widget to always be considered visible.
Given how the code worked before, aBrowsingContext.isActive = false
after that call would deactivate the pres shell, but after my patch it
stops doing so.
We don't really want to un-throttle the refresh driver etc just because
we're preserving layers, so propagate the state to the child process and
account for that in the logic to determine PresShell activeness.
Depends on D118703
Assignee | ||
Comment 8•3 years ago
|
||
Not a big deal, but given we have a lot of them, BrowserParent does it,
and it's low effort, seemed worth doing.
Depends on D118884
Assignee | ||
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Comment 10•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/cb704553fc64
https://hg.mozilla.org/mozilla-central/rev/effd76640491
https://hg.mozilla.org/mozilla-central/rev/49c60a0b4565
Description
•