Open Bug 1530177 Opened 1 year ago Updated 3 days ago

Crash in [@ mozilla::PresShell::DoFlushPendingNotifications] with MOZ_RELEASE_ASSERT(!mForbiddenToFlush)

Categories

(Core :: Layout, defect, P2, critical)

66 Branch
defect

Tracking

()

Tracking Status
firefox-esr60 --- unaffected
firefox65 --- unaffected
firefox66 + fixed
firefox67 + disabled

People

(Reporter: philipp, Assigned: emilio)

References

(Depends on 1 open bug)

Details

(Keywords: crash, leave-open, regression)

Crash Data

Attachments

(1 file)

This bug is for crash report bp-c176ac7d-84b8-474f-9671-aa29d0190224.

Top 10 frames of crashing thread:

0 xul.dll mozilla::PresShell::DoFlushPendingNotifications layout/base/PresShell.cpp:4017
1 xul.dll mozilla::dom::Document::FlushPendingNotifications dom/base/Document.cpp:7065
2 xul.dll class mozilla::dom::Element* nsFocusManager::CheckIfFocusable dom/base/nsFocusManager.cpp:1482
3 xul.dll void nsFocusManager::Focus dom/base/nsFocusManager.cpp:1820
4 xul.dll nsFocusManager::WindowRaised dom/base/nsFocusManager.cpp:691
5 xul.dll void nsWebShellWindow::WindowActivated xpfe/appshell/nsWebShellWindow.cpp:456
6 xul.dll nsWebShellWindow::WidgetListenerDelegate::WindowActivated xpfe/appshell/nsWebShellWindow.cpp:805
7 xul.dll nsWindow::ProcessMessage widget/windows/nsWindow.cpp:5712
8 xul.dll static long nsWindow::WindowProcInternal widget/windows/nsWindow.cpp:4753
9 xul.dll CallWindowProcCrashProtected xpcom/base/nsCrashOnException.cpp:27

crash reports with this signature and MOZ_RELEASE_ASSERT(!mForbiddenToFlush) (This is bad!) are starting to appear in 67.0a1 and 66.0b10.

Flags: needinfo?(emilio)
See Also: → 1438939

I cannot see other reports:

An unexpected error occured :(
We have been automatically informed of that error, and are working on a solution.
error - Forbidden

If you can see them, do all of them have nsImageBoxFrame on the stack? Or is there something else interesting? I guess I can remove this assertion for nsImageBoxFrame for now, though it is really bad. It's the same root cause as bug 1438939.

Flags: needinfo?(madperson)

this query should list more reports: https://bit.ly/2BP21IY
i checked and only a quarter of them had nsImageBoxFrame in their stack...

Flags: needinfo?(madperson)
Depends on: 1530188
Depends on: 1530190

nsIconChannel (for moz-icon:// images) is unsound, see bug 1438939.

nsMenuPopupFrame::Init is also unsound on mac, looks like...

I'll try to get them fixed on trunk, but it's not worth crashing release for
this IMO, given it's pre-existing. The assert in PresShell::~PresShell hopefully
avoids exploitable issues.

I want to avoid crashing but leave this open until the dependent issues are fixed.

Flags: needinfo?(emilio)
Keywords: leave-open
Priority: -- → P3

Comment on attachment 9046206 [details]
Bug 1530177 - Downgrade an assertion to a diagnostic assert since it exposes pre-existing bugs.

Beta/Release Uplift Approval Request

  • Feature/Bug causing the regression: Bug 1525509
  • User impact if declined: Crashes.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Just makes an assertion introduced in bug 1525509 not crash on release, since fixing the dependent pre-existing issues it exposed will take a bit.
  • String changes made/needed: none
Attachment #9046206 - Flags: approval-mozilla-beta?
Summary: Crash in [@ mozilla::PresShell::DoFlushPendingNotifications] → Crash in [@ mozilla::PresShell::DoFlushPendingNotifications] with MOZ_RELEASE_ASSERT(!mForbiddenToFlush)

Comment on attachment 9046206 [details]
Bug 1530177 - Downgrade an assertion to a diagnostic assert since it exposes pre-existing bugs.

Thanks, let's uplift for beta 11.

Attachment #9046206 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

MOZ_RELEASE_ASSERT(!mForbiddenToFlush)(This is bad!) got introduced in 67.0a1 and uplifted to 66.0b10 - so this particular variant of the [@ mozilla::PresShell::DoFlushPendingNotifications] signature the bug was filed for doesn't affect prior versions...

Changing the priority to p2 as the bug is tracked by a release manager for the current nightly.
See How Do You Triage for more information

Priority: P3 → P2

Assigning to Emilio since he already fixed it.

Assignee: nobody → emilio
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5bb743ffae8c
Downgrade an assertion to a diagnostic assert since it exposes pre-existing bugs. r=dholbert

Daniel, there is a commit in central (comment 12) so this should be marked resolved fixed, correct?

Flags: needinfo?(dvarga)

Hi Neha, this bug has leave-open, that's why it wasn't marked as resolved fixed.

Flags: needinfo?(dvarga)

Yeah, this is not crashing release, but dependent bugs need to be fixed for this to be properly fixed.

Marking it disabled for 67 as the MOZ_RELEASE_ASSERT has been downgraded to a diagnostic assert in 67.

Hello Emilio - the dependent bugs listed are now fixed, but I still see crashes in 69 and 70 nightly. Most of the ones in 70 (https://mzl.la/2MeHoNt) have MOZ_DIAGNOSTIC_ASSERT(!mDocument->GetPresShell()) (Where did this shell come from?) as the moz crash reason. Is this a different issue?

Flags: needinfo?(emilio)
Depends on: 1573823

Yeah, that looks like a different issue. I filed bug 1573823 for that.

Flags: needinfo?(emilio)

Well, maybe we should file a new bug for the !mDocument->GetPresShell() assertion and close this one as fixed, your call Marcia.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #19)

Well, maybe we should file a new bug for the !mDocument->GetPresShell() assertion and close this one as fixed, your call Marcia.

I think we can keep this open until the dependent bug in Comment 18 is addressed.

The leave-open keyword is there and there is no activity for 6 months.
:emilio, maybe it's time to close this bug?

Flags: needinfo?(emilio)

no

Flags: needinfo?(emilio)
You need to log in before you can comment on or make changes to this bug.