Closed Bug 668469 Opened 9 years ago Closed 8 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
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
Duplicate of this bug: 450531
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+
https://hg.mozilla.org/mozilla-central/rev/0b399d43b570
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Duplicate of this bug: 761574
You need to log in before you can comment on or make changes to this bug.