GNOME Bugzilla – Bug 462509
ARIA dialogs are not being announced
Last modified: 2008-07-22 19:32:20 UTC
ARIA dialogs are not true windows so onWindowActivated() is not triggered when one of these dialogs appears. There are caretMoved and Focus events being triggered, but unfortunately neither of these event handlers are handling these dialogs properly. I would have expected locusOfFocusChanged() to handle this situation, but updateBraille() is failing for some reason. braille.setFocus() seems to get hung in getLineInfo(). Investigate and implement a new strategy for ARIA dialogs.
Created attachment 92922 [details] [review] first version of ARIA dialogs are not being announced ARIA dialogs are a departure from "treat ARIA widgets like GTK+ widgets" paradigm because ARIA dialogs are not top level windows. As such, the work was done in gecko.py instead of default.py. Two changes were necessary. First, in locusOfFocusChanged I detected if the newly focused obj is a dialog. If it is I set the caret and created both speech and Braille output. I am not sure if this is the best approach but it does seem to work quite well on my dialog test case http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Dialog.html . Next, I may have exposed a Mozilla bug because the dialog has a 'text' object that does not implement IText. Strange! The check for a valid IText handle in braille.py was necessary to get around this.
> Two changes were necessary. First, in locusOfFocusChanged I detected if the > newly focused obj is a dialog. If it is I set the caret and created both > speech and Braille output. With the patch, the logic will continue on in the method if the role is a dialog. Is this the intent? If not, would it be better to just add the dialog role check in to the 'if'? if (oldLocusOfFocus and \ not self.inDocumentContent(oldLocusOfFocus)) \ or (newLocusOfFocus \ and (newLocusOfFocus.role == rolenames.ROLE_DIALOG): > . Next, I may have exposed a Mozilla bug because the dialog has a 'text' > object that does not implement IText. Strange! The check for a valid IText > handle in braille.py was necessary to get around this. This definitely seems like a Mozilla bug and what you've done seems like a good defensive maneuver. Which specific object(s) in http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Dialog.html are showing this behavior, btw?
(In reply to comment #2) > > Two changes were necessary. First, in locusOfFocusChanged I detected if the > > newly focused obj is a dialog. If it is I set the caret and created both > > speech and Braille output. > > With the patch, the logic will continue on in the method if the role is a > dialog. Is this the intent? If not, would it be better to just add the dialog > role check in to the 'if'? Yes, my thinking was that the default script should be called (end of method) and it probably should not be. I've combined with the 'if' as suggested and it works fine. I'll post new patch soon. > > . Next, I may have exposed a Mozilla bug because the dialog has a 'text' > > object that does not implement IText. Strange! The check for a valid IText > > handle in braille.py was necessary to get around this. > > This definitely seems like a Mozilla bug and what you've done seems like a good > defensive maneuver. Which specific object(s) in > http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Dialog.html > are showing this behavior, btw? The behavior was seen for the text object that is the child of the dialog launched from 'Show dialog'. Something has changed in Firefox and this problem is no longer being seen. BTW, the dialog is buried deep in the hierarchy. It is in the third to last section that has children. I believe the defensive code should stay. It is very cheap and who knows how many similar errors are out there,
Created attachment 93292 [details] [review] second version of ARIA dialogs are not being announced patch includes recommendations from Will's previous comment.
> Created an attachment (id=93292) [edit] > second version of ARIA dialogs are not being announced Looks good to me. I say check it in to trunk, mark this as [pending] and let people give it a test drive. If Joanie and Mike come back and say it works for them, this probably should also be checked into the gnome-2-20 branch. Thanks!
Committed to trunk.
Works for me.
This seems to work well with the supplied test case.
This has been retested and continues to work. I'm marking it FIXED.