GNOME Bugzilla – Bug 479848
Orca should not use its own caret or structural navigation in XUL objects
Last modified: 2007-10-11 17:22:21 UTC
Reported on the Orca list: ---------- We develop a XUL application that uses command keys such as arrow keys or single-letter keys. The application runs fine as long as Orca is not started. When Orca starts, it overrides some of the application key bindings with its own key bindings, making the application unusable. Is there a way to prevent this behavior, either in Orca or in the application? (Other than choosing different keys in the application of course.) In case of interest, development sample of the application is available as a Firefox extension at http://www.freebsoft.org/pub/projects/brailchem/bkch.xpi. You can start it from the Firefox menu "Tools/Chemistry studying tool". Then press the "Periodic table" button. Keys such as `t', `h', `l' and arrows don't work when Orca is running. Regards, Milan Zamazal ----------
Created attachment 96121 [details] [review] proposed patch 1. inDocumentContent() should check to see if the documentFrame's URI starts with "chrome://" 2. getDocumentFrame() should be sure that the child it's looking at is actually the active window. 3. useStructuralNavigation() should return False if we're not in document content. 4. In the process of testing the above, I got a traceback from isAriaWidget. We need to do a null check on obj before asking for its attributes. Will: Thoughts?
I have no idea why there are extra links for patch and bug #1. The link to the attachment is correct however. :-)
This has an unexpected side effect in the bookmarks manager. Still investigating, but ignore this patch for now please. Sorry!
In the spirit of documentation, here is the bulk of a message I just posted to the Orca list. Further testing and examination leads me to believe that we don't want to prevent caret and/or structural navigation in XUL applications.... ------------ You know, I just tried your bkch extension with the latest Orca from svn trunk and the latest Firefox. Here's what I noticed: * If I allow Orca to control the caret, there is some text as well as objects that I CAN arrow to/access that I CANNOT arrow to if Gecko is controlling the caret or if Orca is not running. * If structural navigation is enabled and you're in an entry pressing, say, h will cause an "h" to go into that entry as expected. i.e. we're not conflicting there. If we're not in an entry, pressing h will cause Orca to report that there aren't any headings. If you are someone who likes instant find as you type, we'd stomp on that functionality. But, you can still get find as you type going, by pressing "/" first. Plus, what if you had added headings to your app? (Or what if some other app creator decided to add headings?) The intent behind the original (flawed) patch was this: A XUL app is not traditional document content and shouldn't be treated as such. Therefore, Orca should not allow structural navigation to kick in or try to control the caret in XUL apps. Based on what you described and what I'm seeing now, I question the soundness of that approach. For one thing, if an Orca-controlled caret means one can arrow to and read content that one couldn't otherwise arrow to, I'm not comfortable with automatically preventing an Orca-controlled caret. Similarly, if there is the possibility of things like headings appearing in XUL apps (you're allowed to add HTML elements, so my guess would be that this is indeed a possibility), I would hate to automatically prevent that navigational option. When these settings are interfering with the expected behavior, one can quickly toggle them off with Orca+F12 and Orca+Z. In addition, we have an open RFE to implement per-URL scripts, so eventually one could make these settings automatically kick in for just the bkch app and not even have to toggle them. So.... This is all a long way of saying that *in general* I think things may be best left as-is on this front. If there are things that Orca is flat-out doing wrong in your app, we should look at those on a case-by-case basis and determine where things are going wrong (as we did with the combo boxes and caret navigation in your descriptions). -------- I asked Milan for his opinion. I'll add his response here.
There has been a bit of discussion back and forth with Milan's most recent comment being: ------------ We discussed it here more and decided that the easiest solution would be indeed to avoid using conflicting keys in the XUL application. At least with applications targeted at visually impaired users it is possible. ------------ Therefore, I think this bug should be closed out as WONTFIX. When the support for per-URL scripts (and preferences??) is added, I think that will help out on this front. See bug #404422.