Intermittent <test-name> | application crashed [@ mozilla::a11y::Accessible::HandleAccEvent(mozilla::a11y::AccEvent*)]
Categories
(GeckoView :: General, defect, P2)
Tracking
(firefox-esr68 unaffected, firefox68 wontfix, firefox69 wontfix, firefox70 wontfix, firefox73 wontfix, firefox74 wontfix, firefox75 fixed)
People
(Reporter: intermittent-bug-filer, Assigned: eeejay)
References
Details
(Keywords: crash, intermittent-failure, regression)
Crash Data
Attachments
(2 files)
Filed by: asferro [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer.html#?job_id=255175208&repo=try
Full log: https://queue.taskcluster.net/v1/task/As81kVceS66OoE9lGVzwOg/runs/0/artifacts/public/logs/live_backing.log
undefined
Comment 1•6 years ago
•
|
||
Updated•6 years ago
|
| Assignee | ||
Comment 2•6 years ago
|
||
Looks like the content process still has a11y enabled via xpcom. This probably has to do with the AccessFu frame script holding a reference to an xpcom object or having an accessible event listener set up. I can debug this further, but we are in the process of removing the accessibility js layer, so this should hopefully not be an issue soon.
Updated•6 years ago
|
Comment 3•6 years ago
|
||
I'm editing a bunch of GeckoView bugs. If you'd like to filter all this bugmail, search and destroy emails containing this UUID:
e88a5094-0fc0-4b7c-b7c5-aef00a11dbc9
Updated•6 years ago
|
Updated•6 years ago
|
| Assignee | ||
Comment 4•6 years ago
|
||
Now that we don't rely on XPCOM accessibility anymore we shouldn't see
intermittents with accessibility on.
Updated•6 years ago
|
Comment 6•6 years ago
|
||
| bugherder | ||
Updated•6 years ago
|
Description
•