Crash in [@ mozilla::a11y::TextUpdater::Run]
Categories
(Core :: Disability Access APIs, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox-esr68 | --- | unaffected |
firefox68 | --- | unaffected |
firefox69 | --- | unaffected |
firefox70 | --- | fixed |
People
(Reporter: ehsan.akhgari, Assigned: eeejay)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
This bug is for crash report bp-2970cfa5-03ec-4ae9-a6de-e60790190808.
Top 10 frames of crashing thread:
0 xul.dll mozilla::a11y::TextUpdater::Run accessible/base/TextUpdater.cpp:20
1 xul.dll void nsTextBoxFrame::CalcDrawRect layout/xul/nsTextBoxFrame.cpp:1023
2 xul.dll nsresult nsTextBoxFrame::DoXULLayout layout/xul/nsTextBoxFrame.cpp:920
3 xul.dll nsBoxFrame::LayoutChildAt layout/xul/nsBoxFrame.cpp:1201
4 xul.dll nsSprocketLayout::XULLayout layout/xul/nsSprocketLayout.cpp:155
5 xul.dll nsBoxFrame::DoXULLayout layout/xul/nsBoxFrame.cpp:799
6 xul.dll nsSprocketLayout::XULLayout layout/xul/nsSprocketLayout.cpp:453
7 xul.dll nsBoxFrame::DoXULLayout layout/xul/nsBoxFrame.cpp:799
8 xul.dll nsSprocketLayout::XULLayout layout/xul/nsSprocketLayout.cpp:453
9 xul.dll nsBoxFrame::DoXULLayout layout/xul/nsBoxFrame.cpp:799
I got this crash right after clicking on a link to https://www.nytimes.com/2019/08/06/dining/butchers-meat-vegetarian-vegan.html?utm_source=pocket-newtab from the home page, FWIW. this was on the latest Nightly. Visiting the same page again didn't reproduce the crash.
Comment 1•5 years ago
|
||
The stack seems to be missing some frames, probably because of inlining. What I think is actually happening here is that nsAccessibilityService::UpdateLabelValue is being called, which is calling XULLabelAccessible::UpdateLabelValue on an XULLabelAccessible with a null mValueTextLeaf. That means the XULLabelAccessible wasn't re-created when it should have been.
Looking at the crashes, there are some older crashes with the same signature, but with a different (unrelated) stack. All the crashes with stacks like this one are in the last week or so. That would seem to suggest bug 686400.
In bug 686400, these still get re-created, but it happens differently now.
Eitan, do you think this could be another instance of bug 1571616; i.e. we're failing to prune the subtree when a reframe happens on an ancestor? If so, hopefully the fix for that will deal with this.
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
(In reply to James Teh [:Jamie] from comment #1)
Eitan, do you think this could be another instance of bug 1571616; i.e. we're failing to prune the subtree when a reframe happens on an ancestor? If so, hopefully the fix for that will deal with this.
It is a possibility for sure. Lets wait a day to see if this resolves.
Assignee | ||
Comment 3•5 years ago
|
||
This looks like it subsided. Should we close?
Comment 4•5 years ago
|
||
Yes.
Updated•5 years ago
|
Updated•3 years ago
|
Description
•