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

[Bill Cox <waywardgeek gmail com>]

Thanks for all the info, Joanie!  I didn't realize there were so many
bugs.  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.

With my patched version of Firefox, I turned on Orca Caret Navigation,
but kept Grab Focus on Objects off.  This mode seems to work well for
me.  Also, I did some simple tests on large HTML pages, and Orca was
slow while navigating near the end of the document, but had no
noticeable difference between having Orca Caret Navigation on or off.
So, I think it' would be best to have the default be Orca Caret Nav
on, and Grab Focus off.

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