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

[Joanmarie Diggs <joanmarie diggs gmail com>]

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