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

[Milan Zamazal <pdm brailcom org>]

> > > > > "JD" == Joanmarie Diggs <joanmarie diggs gmail com> writes:

    JD> * If I allow Orca to control the caret, there is some text as
    JD> well as object that I CAN arrow to/access that I CANNOT arrow to
    JD> if Gecko is controlling the caret or if Orca is not running.

All the problem is that some XUL elements are not focusable by default.
Most of it can be solved by using the following css declaration:

  description
  {
    -moz-user-focus: normal;
  }

OTOH, when Orca controls the caret application arrow keys don't work.

    JD> * If structural navigation is enabled and you're in an entry
    JD> pressing, say, h will cause an "h" to go into that entry as
    JD> expected.  i.e. we're not conflicting there.  

I'm not sure what you mean by "entry" here exactly.  It works this way
only in input fields.  But if a key binding is bound to another UI
element (such as a button) or defined globally and Orca uses the same
key binding for some function, Orca captures the key binding and it is
not available to the application when the structural navigation is on.
This is a serious conflict.
    
    JD> The intent behind the original (flawed) patch was this: A XUL
    JD> app is not traditional document content and shouldn't be treated
    JD> as such.  Therefore, Orca should not allow structural navigation
    JD> to kick in or try to control the caret in XUL apps.

    JD> Based on what you described and what I'm seeing now, I question
    JD> the soundness of that approach.  For one thing, if an
    JD> Orca-controlled caret means one can arrow to and read content
    JD> that one couldn't otherwise arrow to, I'm not comfortable with
    JD> automatically preventing an Orca-controlled caret.  

This works as long as the application doesn't utilize arrow keys.

    JD> Similarly, if there is the possibility of things like headings
    JD> appearing in XUL apps (you're allowed to add HTML elements, so
    JD> my guess would be that this is indeed a possibility), I would
    JD> hate to automatically prevent that navigational option.  

Again, only if application doesn't define its own keys.

    JD> When these settings are interfering with the expected behavior,
    JD> one can quickly toggle them off with Orca+F12 and Orca+Z.  

I'm afraid this is not as quick.  Imagine a user who uses Firefox both
for browsing web pages and running XUL applications.  Then it's
necessary to perform manual switching all the time.  Why should this be
needed when a computer is available? :-)

    JD> In addition, we have an open RFE to implement per-URL scripts,
    JD> so eventually one could make these settings automatically kick
    JD> in for just the bkch app and not even have to toggle them.

This might be useful but it requires a configuration action on the
user's side.  By default XUL applications should be fully usable
(although not necessarily with the highest comfort) without special
arrangements.  Per-URL scripts would be optional for users who look for
better comfort.

So I'd suggest to disable structural navigation and Orca caret handling
in XUL applications by default.  Switching them on should be still
available with the Orca+F12/Z keys.  And perhaps it might be useful to
allow switching the structural navigation and caret handling modes not
only globally, but also for a particular window or so?  What do you
think?

Regards,

Milan Zamazal