Closed Bug 1698097 Opened 4 years ago Closed 4 years ago

Crash in [@ $_31::__invoke]

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

RESOLVED FIXED
88 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox86 --- unaffected
firefox87 --- unaffected
firefox88 --- fixed

People

(Reporter: aryx, Assigned: Jamie)

References

(Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

6 Nightly 88.0a1 crashes on 2+ devices, all on Linux.

Crash report: https://crash-stats.mozilla.org/report/index/bf52de44-8ee5-4f04-8e3b-5c54f0210310

Reason: SIGSEGV /SEGV_MAPERR

Top 10 frames of crashing thread:

0 libxul.so $_31::__invoke accessible/base/MarkupMap.h:524
1 libxul.so nsAccessibilityService::CreateAccessible accessible/base/nsAccessibilityService.cpp:1004
2 libxul.so mozilla::a11y::TreeWalker::Next accessible/base/TreeWalker.cpp:188
3 libxul.so mozilla::a11y::DocAccessible::CacheChildrenInSubtree accessible/generic/DocAccessible.cpp:2611
4 libxul.so mozilla::a11y::DocAccessible::CacheChildrenInSubtree accessible/generic/DocAccessible.cpp:2620
5 libxul.so mozilla::a11y::DocAccessible::CacheChildrenInSubtree accessible/generic/DocAccessible.cpp:2620
6 libxul.so mozilla::a11y::DocAccessible::CacheChildrenInSubtree accessible/generic/DocAccessible.cpp:2620
7 libxul.so mozilla::a11y::DocAccessible::CacheChildrenInSubtree accessible/generic/DocAccessible.cpp:2620
8 libxul.so mozilla::a11y::DocAccessible::CacheChildrenInSubtree accessible/generic/DocAccessible.cpp:2620
9 libxul.so mozilla::a11y::DocAccessible::CacheChildrenInSubtree accessible/generic/DocAccessible.cpp:2620
Flags: needinfo?(eitan)
Flags: needinfo?(eitan) → needinfo?(jteh)

:evilpie noted in duplicate bug 1698148 that this can reliably be reproduced by going to https://bugs.chromium.org/p/chromium/issues/detail?id=608854.

See Also: → 1699078
Crash Signature: [@ $_31::__invoke] → [@ $_31::__invoke] [@ <T>::__invoke ]

Aha! Distilled test case causing the crash:

data:text/html,
<div id="host" role="table"></div>
<script>
const shadow = host.attachShadow({mode: "open"});
const tr = document.createElement("tr");
tr.setAttribute("role", "row");
tr.innerHTML = "<th>1";
shadow.append(tr);
</script>

Working on a patch.

Assignee: nobody → jteh
Flags: needinfo?(jteh)

We assumed parent content wasn't null because we've already checked that there is a parent table accessible, suggesting there's also parent content.
However, if the tr is at the top level of a shadow root (but the table is not), parent content will be null, causing a crash.
Before the fix for bug 1686123, this was fine because the frame for a shadow root is null and we didn't continue for a null frame.
Now that we do continue for a null frame, we must null check parent content.

Pushed by jteh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3c36ad47bcd7 Null check parent content when checking whether a tr should use ARIARowAccessible. r=morgan
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: