Assertion failure: !mResizeEventFlushObservers.Contains(aPresShell) && !mDelayedResizeEventFlushObservers.Contains(aPresShell) (Double-adding resize event flush observer), at nsRefreshDriver.h:197
Categories
(Core :: Layout, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox72 | --- | unaffected |
firefox73 | --- | wontfix |
firefox74 | --- | fixed |
People
(Reporter: hiro, Assigned: hiro)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
I've seen this assertion occasionally on my local Android x86_64 emulator when I enable the dynamic toolbar on reference-browser.
What I am currently guessing is that firing visual viewport resize events (bug 1586986) somehow ends up causing recursive resize events, but when I was working on bug 1586986 I had never seen this assertion so presumably there may be some changes affecting the behavior since then.
Anyways, I haven't found a reliable way to reproduce this assertion yet.
Assignee | ||
Comment 1•5 years ago
|
||
So the culprit is an AddResizeEventFlushObserver call in nsPresContext::UpdateDynamicToolbar. It's not recursive at all, in fact setVerticalClipping calls from Android application are not aligned with our refresh driver's tick. Anyways, we need to check mResizeEventPending just like what we do in PresShell::ResizeReflowIgnoreOverride.
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
Emilio, do you recall the reason why setting mResizeEventPending to true is outside of if (MOZ_LIKELY(!mDocument->GetBFCacheEntry()))
block? I'd like to introduce a utility function to call AddResizeEventFlushObserver if applicable, it will be something like this;
void PresShell::MaybeAddResizeEventFlushObserver() {
if (!mIsDestroying && !mResizeEventPending &&
MOZ_LIKELY(!mDocument->GetBFCacheEntry())) {
mResizeEventPending = true;
mPresContext->RefreshDriver()->AddResizeEventFlushObserver(this);
}
}
But it's entirely unclear whether there is a case that we need to set mResizeEventPending to true even if we don't observe refresh observer in the case of the document is not in the BF cache?
Comment 3•5 years ago
|
||
I think it'd be just fine (even better) to put it inside.
Assignee | ||
Comment 5•5 years ago
|
||
Assignee | ||
Comment 6•5 years ago
|
||
It's possible that UpdateDynamicTollbarOffset is called repeatedly before we
actually fire a window resize event.
Depends on D60811
Updated•5 years ago
|
Updated•5 years ago
|
Pushed by hikezoe.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/cb8aa19a013c Introduce PresShell::AddResizeEventFlushObserverIfNeeded. r=emilio https://hg.mozilla.org/integration/autoland/rev/e1d84b595756 Use PresShell::AddResizeEventFlushObserverIfNeeded in nsPresContext::UpdateDynamicToolbarOffset. r=botond
Comment 8•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/cb8aa19a013c
https://hg.mozilla.org/mozilla-central/rev/e1d84b595756
Updated•5 years ago
|
Updated•5 years ago
|
Description
•