Re: [orca-list] Problem with orca and webkit in epiphany

[Joanmarie Diggs <jdiggs igalia com>]

Hey Michael.

> at how webkit support is coming along. What is the official status of webkit
> support in orca?

With the exception of what you have found thus far, Orca should be
fine presenting basic content. Over the next week or two, I will be
evaluating exactly where things are status-wize, adding new support in
Orca where the issue is on our side; filing bugs against WebKitGtk
when the issue is on their side.

On a related note, two weeks from now is the WebKitGtk hackfest being
hosted at Igalia. I will be at that event. So not only will I get even
more focused time to work on these issues, I will be in the same room
as Mario (the WebKitGtk accessibility developer). So I think we'll be
able to accomplish quite a bit on Orca + WebKitGtk and also provide a
much more detailed "official status update" afterwards.

Getting back to your bug, as you may have already seen, I opened a new
bug for you in GNOME's bugzilla against Orca:
https://bugzilla.gnome.org/show_bug.cgi?id=664104

It turns out the problem is in WebKitGtk, therefore I also opened a bug there:
https://bugs.webkit.org/show_bug.cgi?id=72382

My suspicion -- which might be totally bogus -- is that you found a
case where the "flattening" of the hierarchy was overlooked. Which
brings me to, what on earth am I talking about with this "flattened
hierarchy" stuff? <smiles>

In a nutshell, WebKitGtk does two extremely useful things for us (Orca
and its users):

1. Implements native caret navigation properly. Benefit: Orca is not
capturing every last arrow press and then trying to figure out where
you are, where the next line might be, put you on that next line,
filter out any events that we triggered as a result of re-positioning
you, etc., etc. Also text selection JustWorks(tm).

2. Flattens the hierarchy of text objects. Benefit: When you navigate
and we get a caret-moved event, Orca doesn't have to try to piece
together a line of text which on the screen is just a line of text,
but in actuality might be made up of different objects.

In other words, all of the heavy lifting is being done by WebKitGtk --
which is in a much better position to know where the caret should go
and what the full text of a line is than Orca is. <smiles> However,
all of that work done by WebKitGtk's accessibility implementation to
make our lives better is not trivial -- especially not the flattening
part. Based on what is being reported as the current line as you
navigate in the code samples looks rather like what I used to see when
the flattening work was still very much under construction.

> Could this be related to the issue in gedit where lines were being run into
> one although the cursor was still respecting the lines when moving?

Nope. That problem was a regression which occurred in Gtk+ 3 when they
were integrating Gail (so that it is no longer a separate module). A
fix has been committed to Gtk+ master for that issue and I have been
told that they will also add that fix when the new the next stable
Gtk+ release.

Hope this helps clarify things. If not, you know where to find me. <grins>

Take care.
--joanie