Closed Bug 1693687 Opened 3 years ago Closed 1 month ago

Crash in [@ mozilla::PresShell::ResizeReflowIgnoreOverride]

Categories

(Core :: Layout, defect)

Unspecified
Windows 10
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox86 --- wontfix
firefox87 --- fix-optional

People

(Reporter: mccr8, Unassigned)

References

Details

(Keywords: crash, regression)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/3843c0c9-a3f1-461f-add0-5ba4a0210204

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(mPresContext->GetVisibleArea().height != nscoord((1 << 30) - 1)) (height should not be NS_UNCONSTRAINEDSIZE after reflow)

Top 10 frames of crashing thread:

0 xul.dll mozilla::PresShell::ResizeReflowIgnoreOverride layout/base/PresShell.cpp:2136
1 xul.dll nsDocumentViewer::GetContentSizeInternal layout/base/nsDocumentViewer.cpp:2780
2 xul.dll nsDocumentViewer::GetContentSize layout/base/nsDocumentViewer.cpp:2812
3 xul.dll nsGlobalWindowOuter::SizeToContentOuter dom/base/nsGlobalWindowOuter.cpp:5559
4 xul.dll mozilla::dom::Window_Binding::sizeToContent dom/bindings/WindowBinding.cpp:5792
5 xul.dll mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::MaybeCrossOriginObjectThisPolicy, mozilla::dom::binding_detail::ThrowExceptions> dom/bindings/BindingUtils.cpp:3233
6 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:594
7 xul.dll Interpret js/src/vm/Interpreter.cpp:3309
8 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:619
9 xul.dll JS::Call js/src/jsapi.cpp:2861

There are crashes on other builds with this signature, but it looks like the Nightly crashes with this release assert started in the 20210203214546 build.

This is the set of new changes for that build: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ca7a3f92939dae5d54226dbc237120bef5d138e9&tochange=32690d048b75cc54ead9118c98333d5442d2c6be

Emilio, it looks like you added that assert a while ago. Any ideas? Thanks.

Flags: needinfo?(emilio)

Not particularly. I just moved the assertion and turned it into a diagnostic assert. It seems like we end up with a massive size...

This could potentially legitimately happen on some websites if they use well, massive sizes a window, then they call sizeToContent, but it seems unlikely that's what's going on... We should consider unexposing this method to content anyhow, since other browsers don't implement it.

It seems we're crashing the parent process if I'm reading the report correctly, so it seems the stack is for one of our internal callers of sizeToContent(), like a dialog... But hard to know what went on without being able to repro.

Flags: needinfo?(emilio)

I don't know if they are related, but in the range of changesets I put in comment 0, there are two, bug 1690715 and bug 1690166, that mention reflow.

This might be a dupe of bug 1691205 (I just landed a fix). That bug only affects users that have questionable userChrome.css styles and enable those with the hidden pref...

Marking S4 for now; low volume and doesn't seem directly actionable at this point. Let's see if this still shows up after Mats' fix in bug 1691205; if so we may need to look again.

Severity: -- → S4
Depends on: 1691205

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.