GNOME.org
 

Re: [orca-list] Debugging communication between Orca and firefox

On Fri, 2010-04-23 at 14:38 -0400, Bill Cox wrote:

Thanks for all the info, Joanie!  I didn't realize there were so many
bugs.


Heheh. You mean those ten? Or did you find our "Bugs blocking Orca
support" metabug in the Mozilla bugzilla? At the moment it says we're
depending on 353 open bugs.
https://bugzilla.mozilla.org/showdependencytree.cgi?id=374212&hide_resolved=1


  If you're willing to help, I'll see what I can do about these
problems over the next few months, assuming the Firefox guys are also
willing to incorporate bug fixes.  Just let me know what you feel is
the most critical bug still there, and I'll put it on my list.


The ten I listed need to be fully evaluated/re-triaged (what issues
still remain?). But they are the sorts of issues I've spent many (many,
many) hours over the years trying to hack around. The reason we have a
full 3 hours worth of Firefox regression tests is because of all that
hacking and all of the variety of markup one can come across.

There are other bugs -- ones we cannot hack around well or at all -- but
most of those seem to be on the plates of the Mozilla a11y guys.


slow while navigating near the end of the document, but had no
noticeable difference between having Orca Caret Navigation on or off.


Interesting.... It might be this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=453605
text.getAttributes() can take an extraordinarily long time to return
given a sufficiently large text 

For that one, my test case was War and Peace. Literally. Wanted to make
a point.... <shrugs>


So, I think it' would be best to have the default be Orca Caret Nav
on, and Grab Focus off.


Which is how we (i.e. upstream) do it currently.

I still want to pursue some sort of hybrid solution. Mind you, I've been
wanting to do so (and have even started off and on) for several years.
But then something else always comes up and/or Gecko burnout kicks in.
So I'd be willing to help your efforts should you be interested in
trying to implement a hybrid solution in Orca. :-)

Basically the principles are these:

1. Firefox isn't completely screwed up; just sorta screwed up. <grin>
What I mean is that there are places where I'd bet money that Firefox
would get navigation and the accessible text implementation correct,
such as:

* Within a simple text object (paragraph, heading, etc. with no embedded
object characters other than perhaps links).

* Amongst several simple text objects in a row (heading 1 to paragraph 1
to paragraph 2 to paragraph 3 to heading 2 and so on).

* Amongst items in a simple, ordered list.

2. Orca has to check the current circumstances anyway each and every
time you arrow with Orca controlling the caret. Examples:

* If you're not even in document content (e.g. you're in a firefox
dialog), Orca shouldn't control the caret even if it's your preference
for it to do so.

* If you're in certain ARIA widgets, Orca shouldn't control the caret
even if it's your preference for it to do so.

* If you're in a focusable list, Orca shouldn't control the caret even
if it's your preference for it to do so.

* Etc., etc., etc.

Therefore, what's a few more checks? (Note that's actually not a
rhetorical question. I think we'll see a performance improvement if we
delegate control to Firefox when were certain it is worthy and capable
of doing so. But I could be wrong. Performance analysis is most
certainly in order. But for now, let's assume that my hunch is right.)

3. Another option might be to give Gecko a bit more freedom and do
post-checking. While I'd need to verify this, I'm pretty sure that with
non-dynamic content we get accessibles in reading order.

Consider the Orca wiki with you *not* logged in. Press Ctrl+Home. You
should wind up at the top (it does work sometimes....). Now Down Arrow.
(This is all without Orca by the way.) When I do this, I skip completely
past the live.gnome.org heading, the search entry and buttons, the links
below that (home, recent changes, schedule, etc) and wind up at the end
(not the beginning) of the line of text that starts with "Translations
of this page." Try to arrow (*not* Tab) into the Contents box (I can't.
Can you?).

Now look at the accessible hierarchy for the same content. You should
see that these things are in the same order. So it's pretty obvious that
I (or rather Gecko's caret navigation) skipped over accessibles. From
the accessible text interface, I can tell that I'm not at the beginning
of the line, etc., etc. So hypothetically, pending actually trying it,
performance testing, regression testing, etc., etc. I think in some
cases at least, we could something in the ballpark of:

* Let Gecko control the caret

* Keep track of our present location

* Wait for the caret-moved event

* Consider the position where Gecko wants to place us, and if it's
whack, we move the caret where we know it belongs and present the unit
of text based on the navigational keys used.

Also note that if we could get the Mozilla guys to fix yet another bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=411914
Please implement RELATION_FLOWS_TO/RELATION_FLOWS_FROM 

We could use that to validate the proposed new location.

4. 



I'll upload a patched Firefox to Vinux for some better user testing.
I'm hoping we can ship Vinux 3.0 with this patched version.  I always
cheat and use the mouse, but if there are significant problems in my
patch, I think the Vinux guys will find them!  I'll also upload the
revised patch to the Mozilla bug page.

Thanks,
Bill

On Fri, Apr 23, 2010 at 1:50 PM, Joanmarie Diggs
<joanmarie diggs gmail com> wrote:

On Fri, 2010-04-23 at 12:30 -0400, Bill Cox wrote:

I think I have caret navigation in Firefox mostly working now.


I'd be curious to see that. In particular, how well does it work in the
scenarios from these still-open bugs:

1. caret browsing - bad initial position
https://bugzilla.mozilla.org/show_bug.cgi?id=144000
(By the way, if your answer to this one is "no problem, I can use Ctrl
+Home, I think you'll find that in quite a few real-word pages that
fails. We override that binding in Orca. Did so at user request because
of the repeated failures using Firefox's Ctrl+Home)

2. caret eventually gets stuck when trying to scroll with PageDown/PageUp keys
https://bugzilla.mozilla.org/show_bug.cgi?id=205846
(Note, even though the summary says PageDown/PageUp, looks like there's
some comments about problems with arrow keys as well. Mind you, I'm just
skimming over things at the moment.)

3. Can't move caret into floats using up/down arrow keys
https://bugzilla.mozilla.org/show_bug.cgi?id=369855
(The web is crawling with floats. It would be nice to see this fixed.)

4. position: absolute interferes with keyboard navigation (Ctrl
+Home/End) within page content
https://bugzilla.mozilla.org/show_bug.cgi?id=372624
(I forgot about this one. I filed it over 3 years ago. This would be
nice to have fixed.)

5. Frame code and Caret code need work to allow caret in more places
https://bugzilla.mozilla.org/show_bug.cgi?id=85505
(Some of the reported issues were fixed; looks like a few remain)


I am
seeing a strange problem I want to debug.  When I use left and right
arrow keys, Orca speaks the character to the right of the caret.


If you've disabled Orca's control of the caret, I suspect it's falling
back on some code in the Gecko script that needs some love. So much time
in the day, yadda, yadda, yadda. :-( I suspect in many cases, things are
probably also falling back on the default script. The problem is that
neither of those areas of code expect multiple embedded object
characters. Providing access to a given block of Gecko text involves
piecing together lots and lots of bits by descending into the objects
represented by the EOC's and using the accessible text interface to
access each object's content. Which brings me to a few more bugs. These
impact us no matter what caret mode you're in. However, there's lots of
fine-tuned guessing that I suspect you might have to implement in the
Gecko script if you want to completely abandon Orca's control of the
caret.

6. The display:inline style interferes with getTextAtOffset()
https://bugzilla.mozilla.org/show_bug.cgi?id=409497

7.text.getTextAtOffset broken for TEXT_BOUNDARY_LINE_START
https://bugzilla.mozilla.org/show_bug.cgi?id=384101

8. getTextAtOffset sometimes returns more than a character for TEXT_BOUNDARY_CHAR
https://bugzilla.mozilla.org/show_bug.cgi?id=464559

9. Incorrect results returned by getTextBeforeOffset
https://bugzilla.mozilla.org/show_bug.cgi?id=493354

I believe there are a few other similar such bugs, but I'd have to look
deeper to be sure.... But the nine items above are the key issues. They
boil down to: We cannot navigate page content in its entirety on pages
with complex layout. And even when you can, when we ask for the text so
that we can present what you've just navigated to you, we sometimes get
the wrong thing.

You can typically do some spot checking by getting the extents of a
character, but since the impact of some of the above text bugs is that
you get bogus offsets, you'll need to find a way to sanity check those.
Fortunately once you do that, the extents tend to be reliable spatially.
With the exception of list bullets and item numbers:

10. getRangeExtents reports (0, 0, 0, 0) for list item bullets
https://bugzilla.mozilla.org/show_bug.cgi?id=360003

And keep in mind that the above text issues can confront you in each and
every embedded object character you come across.

Mind you, this is not to discourage you; in fact, I hope it encourages
you. We've been begging and pleading with Mozilla folks to fix the above
issues. For years in some cases. If you can fix them and get your
changes committed to their code base, I'll worship the very ground you
walk on. I may even be willing to help you with the Embedded Object
Character stuff. <grins>


However, if I enter a link, either by typing tab or with the arrow
keys, Orca stops speaking characters which are not in links.


Keep in mind that Orca gets tons and tons and tons of events, many of
which are irrelevant to the task the user is performing at any given
moment. So.... My guess (note, I've not looked; merely a theory) is the
following:

1. You arrow into the link. This causes the link to gain focus and issue
a focus: event as well as a couple of object:state-changed:focus events
(one for what claimed focus; one for what gave it up.) In response, Orca
notes that the locusOfFocus must be in the link. Otherwise it wouldn't
have claimed to have focus, right?

2. Arrowing around within the link would (or should, unless they've gone
missing) cause object:text-caret-moved events to be emitted. Orca has to
decide what to do with them. It notices that they are coming from the
focused object/locusOfFocus, ergo, they're probably worth presenting to
you the user.

3. You arrow out of the link. This causes the caret to move into, say,
some text marked up as a paragraph. This paragraph is not focusable.
Therefore, the Document Frame claims focus. But the caret-moved events
we start getting are from the paragraph which never claimed to have
focus and is therefore not the locusOfFocus. So we don't present them.


switch to another application with Alt+tab, and then back again, Orca
once again reads characters as I move over them.


4. When you Alt+Tab out of the page and back into it, Orca needs to
figure out where the heck you are, so it goes looking and sets the
locusOfFocus accordingly. As a result, we start believing that the
caret-moved events from the paragraph really are of interest, and
present them -- until you cross another object boundary in the form of
an embedded object character. Then all bets are off again.


Is there any way to dump all the communication between Orca and
FIrefox?


I've not tried to do so, but I suspect you can do something clever with
dtrace.


I've got an Orca debug file which I attached to another
e-mail, which is being held up because of it's size.


I think that it was approved over 12 hours ago.

Anyhoo, sorry to be long winded. Hope it is of some use.
--joanie
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]