Crash in [@ mozilla::PresShell::ResizeReflowIgnoreOverride]
Categories
(Core :: Layout, defect)
Tracking
()
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
Reporter | ||
Comment 1•3 years ago
|
||
Emilio, it looks like you added that assert a while ago. Any ideas? Thanks.
Comment 2•3 years ago
|
||
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.
Reporter | ||
Comment 3•3 years ago
|
||
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.
Comment 4•3 years ago
|
||
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...
Comment 5•3 years ago
|
||
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.
Updated•3 years ago
|
Comment 6•1 month ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•