Closed Bug 1611038 Opened 5 years ago Closed 5 years ago

Assertion failure: !mResizeEventFlushObservers.Contains(aPresShell) && !mDelayedResizeEventFlushObservers.Contains(aPresShell) (Double-adding resize event flush observer), at nsRefreshDriver.h:197

Categories

(Core :: Layout, defect, P2)

Unspecified
Android
defect

Tracking

()

RESOLVED FIXED
mozilla74
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.

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.

Regressed by: 1523541
Has Regression Range: --- → yes

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?

Flags: needinfo?(emilio)

I think it'd be just fine (even better) to put it inside.

Flags: needinfo?(emilio)

Great! Thank you!

It's possible that UpdateDynamicTollbarOffset is called repeatedly before we
actually fire a window resize event.

Depends on D60811

Attachment #9122595 - Attachment description: Bug 1611038 - Introduce PresShell::MaybeAddResizeEventFlushObserver. r?emilio → Bug 1611038 - Introduce PresShell::AddResizeEventFlushObserverIfNeeded. r?emilio
Attachment #9122596 - Attachment description: Bug 1611038 - Use PresShell::MaybeAddResizeEventFlushObserver in nsPresContext::UpdateDynamicToolbarOffset. r?botond → Bug 1611038 - Use PresShell::AddResizeEventFlushObserverIfNeeded in nsPresContext::UpdateDynamicToolbarOffset. r?botond
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
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla74
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: