GNOME Bugzilla – Bug 466764
[pending] Orca doesn't provide access to alerts that appear when page is loading in FF3
Last modified: 2008-07-22 19:28:24 UTC
Reported by Marco in #orca. Steps to reproduce: 1. Launch FF3 2. Navigate to: http://angemo.carookee.com Expected results: The resulting window prompting you for a username and password would be spoken. Actual results: Sometimes it's spoken; sometimes it's not. It seems that sometimes it claims to be a dialog box; other times it claims to be an alert. We're now on the look out for such dialogs; we're not on the look out for alerts. Patch to follow.
Created attachment 93686 [details] [review] patch to hopefully solve the problem Marco please see if this works for you. Thanks!
Joannie, no, this does not change the situation on my Feisty system. But I have made the following observations: 1. If I do the WhereAmI keystroke, I get the current textbox, password, checkbox or button spoken. 2. When focus is on the user text or the password field, braille shows the app title, the "Authorization Required" as an alert, and the prompt for the two boxes. For the checkbox and buttons, however, no braille representation is given. When tabbing to them, the password prompt remains. 3. If I now perform the WhereAmI keystroke, for the checkbox, and the two buttons, the app title and alert titles are cleared, and only the checkbox or button caption, along with the type and state, are brailled.
I chatted with Marco about this in #orca. After doing the make install and restarting Orca, things are now working for him. Will okay to check this in?
(In reply to comment #3) > I chatted with Marco about this in #orca. After doing the make install and > restarting Orca, things are now working for him. > > Will okay to check this in? > Looks glorious. Thanks! In looking at this patch, I'm seeing some stylistic things we probably should start cleaning up, but not for the purpose of this patch. We have code peppered throughout that does stuff like: isField = containingForm and \ obj.role != rolenames.ROLE_LINK and \ obj.role != rolenames.ROLE_MENU_ITEM and \ obj.role != rolenames.ROLE_LIST_ITEM and \ obj.role != rolenames.ROLE_UNKNOWN and \ obj.state.count(atspi.Accessibility.STATE_FOCUSABLE) and \ obj.state.count(atspi.Accessibility.STATE_SENSITIVE) and if isinstance(zone, TextZone) and \ ((zone.accessible.role == rolenames.ROLE_TEXT) \ or (zone.accessible.role == rolenames.ROLE_PASSWORD_TEXT) \ or (zone.accessible.role == rolenames.ROLE_TERMINAL)): At some point, we probably should consider making these use lists for comparing roles (ignore my spacing here because FF is using a proportional font for this comment): isField = containingForm \ and not obj.role in [rolenames.ROLE_LINK, rolenames.ROLE_MENU_ITEM, rolenames.ROLE_LIST_ITEM, rolenames.ROLE_UNKNOWN] \ and obj.state.count(atspi.Accessibility.STATE_FOCUSABLE) \ and obj.state.count(atspi.Accessibility.STATE_SENSITIVE) and if isinstance(zone, TextZone) \ and zone.accessible.role in [rolenames.ROLE_TEXT, rolenames.ROLE_PASSWORD_TEXT, rolenames.ROLE_TERMINAL]: Just food for thought for the future and nothing that needs to be done right away.
Created attachment 93746 [details] [review] use lists when comparing roles I know better. Changed the one in this patch and grabbed the other one I was guilty of. :-) Thanks Will. This version has been committed to both the 2.20 branch and to trunk.
(In reply to comment #5) > Created an attachment (id=93746) [edit] > use lists when comparing roles > > I know better. Changed the one in this patch and grabbed the other one I was > guilty of. :-) Thanks Will. This version has been committed to both the 2.20 > branch and to trunk. > No problem! I wasn't expecting you to change them this time, but thanks for doing so! BTW, when I looked at the following code, I wondered if there were a better way: inDialog = self.getContainingRole(event.source, rolenames.ROLE_DIALOG) if not inDialog: inDialog = self.getContainingRole(event.source, rolenames.ROLE_ALERT) One way might be to turn the second parameter of getContainingRole into a list. Another might be to do something like the following, which I believe works in Python (it will give you the value from the first non-None thing or None if they are both None): inDialog = self.getContainingRole(event.source, rolenames.ROLE_DIALOG) \ or self.getContainingRole(event.source, rolenames.ROLE_ALERT) NOTE: I'm just thinking out loud (well, if you're using TTS anyway) on this. I'm not calling for changes. :-)
I think Scott was suggesting a while back that getContainingRole() should take a list. It probably should. Your other suggestion is cool as well. Is it time to start a post-2.20 Gecko.py refactor bug and add things to it? :-)
> I think Scott was suggesting a while back that getContainingRole() should take > a list. It probably should. I agree. > Is it > time to start a post-2.20 Gecko.py refactor bug and add things to it? :-) Or, maybe a specific "refactor getContainingRole to take a list" RFE. :-)
One specific RFE comin' up: Bug 469083. :-) Anything else that needs doing on this bug or is it time to close it as FIXED?
(In reply to comment #9) > One specific RFE comin' up: Bug 469083. :-) > > Anything else that needs doing on this bug or is it time to close it as FIXED? > I think it's good to close. :-) Thanks!