Re: [orca-list] keys in conflict with XUL application keys

[Joanmarie Diggs <joanmarie diggs gmail com>]

Hi again Milan.

> I see.  Well, without the patch, after toggling structural navigation
> off and disabling Orca caret control things seem to work as expected.

Excellent.  Thanks for the update.

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 
object 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 their 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).

Milan, what do you think?

--joanie