Closed
Bug 987026
Opened 10 years ago
Closed 10 years ago
Crash when adopting a focused element [@ mozilla::a11y::FocusManager::ProcessDOMFocus]
Categories
(Core :: Disability Access APIs, defect)
Core
Disability Access APIs
Tracking
()
VERIFIED
FIXED
mozilla31
Tracking | Status | |
---|---|---|
firefox31 | --- | verified |
People
(Reporter: jruderman, Assigned: surkov)
Details
(Keywords: crash, testcase)
Crash Data
Attachments
(3 files)
1. Enable accessibility by pasting the following into the Browser Console: Components.classes["@mozilla.org/accessibilityService;1"].getService(Components.interfaces.nsIAccessibleRetrieval); 2. Load the testcase.
Reporter | ||
Updated•10 years ago
|
Attachment #8395528 -
Attachment description: hac.html → testcase
Reporter | ||
Comment 1•10 years ago
|
||
mozilla::a11y::FocusManager::ProcessDOMFocus derefs document, then checks whether it's null :( This might have been introduced in bug 977170. Or maybe that patch just made the problem more obvious in the source code.
Reporter | ||
Updated•10 years ago
|
Crash Signature: [@ mozilla::a11y::FocusManager::ProcessDOMFocus]
[@ mozilla::a11y::DocAccessible::GetAccessibleEvenIfNotInMap]
Assignee | ||
Comment 2•10 years ago
|
||
nothing to process if accessible doesn't exist. It's interesting though where the focus goes when focsued element gets adopted, presumably it should go to the document but if not it just disappears then it's rather usability bug and we don't care. I hope it doesn't open a hole for tricks though.
Assignee: nobody → surkov.alexander
Attachment #8397131 -
Flags: review?(jwei)
Updated•10 years ago
|
Attachment #8397131 -
Flags: review?(jwei) → review+
Assignee | ||
Comment 3•10 years ago
|
||
http://hg.mozilla.org/integration/mozilla-inbound/rev/f65515f94aab
Assignee | ||
Updated•10 years ago
|
OS: Mac OS X → All
Hardware: x86_64 → All
I had to back this out in https://hg.mozilla.org/integration/mozilla-inbound/rev/a1223ec7312a for apparently breaking all Linux64 ASAN mochitests: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&jobname=Ubuntu%20ASAN%20VM%2012.04%20x64%20mozilla-inbound%20opt%20test%20mochitest-&rev=f65515f94aab This doesn't really make sense to me, especially with the failure that's happening in those tests, but retriggering previous pushes didn't make them fail and everything since this landed has failed. If things are still failing on this backout, I'll comment in here and you can reland this.
Flags: needinfo?(surkov.alexander)
Assignee | ||
Comment 5•10 years ago
|
||
It doesn't make sense to me because non-a11y tests were failing as well. Also I tried a try server and it was clean. Something else must be guilty.
Flags: needinfo?(surkov.alexander)
Yeah, bug 957965 just needed to CLOBBER. Relanded this in http://hg.mozilla.org/integration/mozilla-inbound/rev/8a05309d1921 Sorry for the churn, here.
Comment 7•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/f65515f94aab
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Comment 8•10 years ago
|
||
Reproduced in Nightly 2014-03-25. Verified fixed 31.0a1 (2014-03-30), Win 7 x64.
Status: RESOLVED → VERIFIED
status-firefox31:
--- → verified
You need to log in
before you can comment on or make changes to this bug.
Description
•