Closed Bug 668469 Opened 13 years ago Closed 12 years ago

"Assertion failure in -[mozRootAccessible didReceiveFocus]" "trying to set focus to ignored element"

Categories

(Core :: Disability Access APIs, defect)

x86_64
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla17

People

(Reporter: jruderman, Assigned: hub)

References

Details

(Keywords: testcase)

Attachments

(3 files)

Attached file testcase (deleted) —
1. Build Firefox with --enable-accessibility. 2. Enable accessibility, e.g. by pasting the following into the js console: Components.classes["@mozilla.org/accessibilityService;1"] .getService(Components.interfaces.nsIAccessibleRetrieval); 3. Load the testcase. 4. Click the button. Result: 2011-06-30 01:59:27.785 firefox-bin[55214:903] *** Assertion failure in -[mozRootAccessible didReceiveFocus], /Users/jruderman/trees/mozilla-central/accessible/src/mac/mozAccessible.mm:582 2011-06-30 01:59:27.786 firefox-bin[55214:903] Mozilla has caught an Obj-C exception [NSInternalInconsistencyException: trying to set focus to ignored element! ((0x129cb4b10) AXUnknown)] "Regression" from bug 524775. This assertion is also mentioned in bug 450531, fwiw.
I can't reproduce this on my tree....
Still happens for me, using a debug build from Tinderbox on Mac OS X 10.6.
(In reply to Jesse Ruderman from comment #2) > Still happens for me, using a debug build from Tinderbox on Mac OS X 10.6. Which tinderbox build? One that does enable a11y or the regular one (that has it disabled)?
I can reproduce with the build in https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx64-debug/1323730278/, for example. It's built with --enable-accessibility. (IIRC, the "regular" Mac debug builds have accessibility enabled iff they are 64-bit builds.)
Even with that built I can't reproduce...
I have gotten that with DOM Inspector.
Blocks: 761574
Unlike I said in comment 5 I completely can reproduce with the test case.
QA Contact: accessibility-apis
Assignee: nobody → hub
Comment on attachment 654200 [details] [diff] [review] Don't ignore focusable elements. r= This is as proposed in bug 761574
Attachment #654200 - Flags: review?(surkov.alexander)
Comment on attachment 654200 [details] [diff] [review] Don't ignore focusable elements. r= Review of attachment 654200 [details] [diff] [review]: ----------------------------------------------------------------- r=me, thank you ::: accessible/src/mac/mozAccessible.mm @@ +101,5 @@ > > // unknown (either unimplemented, or irrelevant) elements are marked as ignored > // as well as expired elements. > + return !mGeckoAccessible || ([[self role] isEqualToString:NSAccessibilityUnknownRole] && > + !(mGeckoAccessible->State() & states::FOCUSABLE)); use NativeInteractiveState
Attachment #654200 - Flags: review?(surkov.alexander) → review+
Hub, sorry to say that, but InteractiveState should be used instead, otherwise aria-descendant logic which affects on focusable state is ignored.
ok, I'll fix it.
Whiteboard: [leave open]
Attachment #654200 - Flags: checkin+
Attachment #655261 - Flags: review?(surkov.alexander)
Comment on attachment 655261 [details] [diff] [review] Part 2: use InteractiveState() instead of NativeInteractiveState(). Review of attachment 655261 [details] [diff] [review]: ----------------------------------------------------------------- you don't really need review for this
Attachment #655261 - Flags: review?(surkov.alexander) → review+
Attachment #655261 - Flags: checkin+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: