Crash in [@ mozilla::RestyleManager::SnapshotFor]
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
People
(Reporter: aryx, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: crash)
Crash Data
11 crashes from 11 installs of Firefox 144 betas which is more than for all older builds combined. Bug 769207 and bug 1987024 touched these files last. Could they be related?
Crash report: https://crash-stats.mozilla.org/report/index/31683dbe-ebd6-4db1-9ef5-a61010250918
MOZ_CRASH Reason:
MOZ_DIAGNOSTIC_ASSERT(!mInStyleRefresh)
Top 10 frames:
0 xul.dll mozilla::RestyleManager::SnapshotFor(mozilla::dom::Element&) layout/style/RestyleManager.cpp:3171
0 xul.dll mozilla::RestyleManager::ElementStateChanged(mozilla::dom::Element*, mozilla:... layout/style/RestyleManager.cpp:3470
1 xul.dll mozilla::PresShell::ElementStateChanged(mozilla::dom::Document*, mozilla::dom... layout/base/PresShell.cpp:4711
1 xul.dll mozilla::dom::Document::ElementStateChanged(mozilla::dom::Element*, mozilla::... dom/base/Document.cpp:8815
1 xul.dll mozilla::dom::Element::NotifyStateChange(mozilla::dom::ElementState) dom/base/Element.cpp:390
2 xul.dll mozilla::dom::Element::State() const dom/base/Element.h:312
2 xul.dll mozilla::dom::HTMLTextAreaElement::IsValueEmpty() const dom/html/HTMLTextAreaElement.h:374
2 xul.dll mozilla::dom::HTMLTextAreaElement::UpdatePlaceholderShownState() dom/html/HTMLTextAreaElement.cpp:1076
2 xul.dll mozilla::dom::HTMLTextAreaElement::OnValueChanged(mozilla::TextControlElement... dom/html/HTMLTextAreaElement.cpp:1089
3 xul.dll mozilla::TextControlElement::OnValueChanged(mozilla::TextControlElement::Valu... dom/html/TextControlElement.h:210
|
||
Comment 1•1 month ago
|
||
The bug is linked to a topcrash signature, which matches the following criterion:
- Top 10 AArch64 and ARM crashes on beta
For more information, please visit BugBot documentation.
I feel it's odd if this is caused by bug 769207 or bug 1987024. Bug 769207 removed the paths disabled by the pref. And bug 1987024 just changed the structure of some classes.
The problem is here:
mozilla::dom::HTMLTextAreaElement::UpdatePlaceholderShownState()
mozilla::dom::HTMLTextAreaElement::OnValueChanged(mozilla::TextControlElement::ValueChangeKind, bool, nsTSubstring<char16_t> const*)
mozilla::TextControlElement::OnValueChanged(mozilla::TextControlElement::ValueChangeKind, nsTSubstring<char16_t> const&)
mozilla::TextControlState::SetValue(nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const*, mozilla::EnumSet<mozilla::TextControlState::ValueSetterOption, unsigned int> const&)
mozilla::TextControlState::SetValue(nsTSubstring<char16_t> const&, mozilla::EnumSet<mozilla::TextControlState::ValueSetterOption, unsigned int> const&)
mozilla::TextControlState::UnbindFromFrame(nsTextControlFrame*)
While destroying the text control frame, HTMLTextAreaElement tries to handle placeholder shown state...
Oh, wait, this is impossible:
mozilla::dom::Element::NotifyStateChange(mozilla::dom::ElementState) dom/base/Element.cpp:390
mozilla::dom::Element::State() const dom/base/Element.h:312
in this case, the web app has an input event listener which is kicked by a composition string change of IME and which retrieves a style value. Then, here requires a flush for some properties. Then, the frame of <input> is reframed and TextControlState::UnbindFromFrame needs to set the value to the latest one. Only the new value or the last value is empty and the other is not empty and needs to reset the empty value state to show/hide the placeholder text. So, to reproduce this bug, we need to change a style and retrieve a style value to flush the layout after setting the value but it's not yet applied to the element.
To reproduce this bug, we need to make the situation that the element thinks the value is different state from the actual value when input event is fired.
The state is set only by OnValueChanged() overrides. They are called when the value is set or the value is modified by the editor before input event. So, basically, before the input event is fired, the element should have the latest empty value state. However, if the TextEditor has already been destroyed or the text control frame has already or is destroyed, TextEditor fails updating the state in the element.
|
||
Comment 7•23 days ago
•
|
||
And another necessary condition is, the text control frame should be dirty at dispatching the input event. After dispatching beforeinput nor textInput event, it seems that TextEditor does not flush the layout. So, I guessed that beforeinput or textInput listener can make the frame dirty. Then, TextEditor fails to update the state before dispatching input event. However, I cannot reproduce this bug with this simplest testcase. So, I'm still missing something...
Oh, I realized that why this is not reported from the nightly testers?? Some prefs enabled only in the nightly channel prevent this crash? Or has this bug already been fixed in the nightly channel?
|
||
Comment 9•22 days ago
|
||
The crashes appear to have stopped with 144.0b7. Could have been the switch to late Beta. Otherwise, here's the pushlog for that:
https://hg-edge.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=FIREFOX-ANDROID_144_0b6_RELEASE&tochange=FIREFOX-ANDROID_144_0b7_RELEASE&branch=default
The assertion is MOZ_DIAGNOSTIC_ASSERT, so I think switching to the late beta causes disabling the assertion.
On the other hand, there is no crash reports from the nightly channel...
|
|
||
Comment 11•12 days ago
|
||
Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.
For more information, please visit BugBot documentation.
It seems that nobody reproduces this bug since 146. So, this must have already been fixed by another bug.
Description
•