Re: [orca-list] a couple of accessibility bugs when running under wayland



hi
Sure thing. I'll get on it. If this is indeed a wayland bug, it's bug
filing time over at gnome. Do I send you the debug files or just the
differences I find?
Thanks
Kendell clark


On 10/09/2015 10:16 AM, Joanmarie Diggs wrote:
Hi Kendell.

Since I'm working on web-related tasks at the moment, perhaps you could
do some triage yourself:

1. Capture a full debug.out using GNOME Shell for X where the bug does
   not occur.
2. Capture a full debug.out using GNOME Shell for Wayland where the bug
   does occur.

You of course will want to perform the exact same steps for each. Then:

3. Look at the first debug.out to figure out what caused Orca to speak
   what you expected. It should be contained in event processing.
4. Look at the second debug.out to see if that same event was seen by
   Orca.

In step 4, if the event is completely absent, that's your bug. And it's
not an Orca bug. If Orca doesn't get the right events, Orca cannot do
the right thing.

On the other hand, if in step 4 the event is present when using Wayland,
then look compare each event looking at the states and other details.
What is different between the two? While this may be an Orca bug, if all
you changed is X versus Wayland, my guess is that needed information is
missing or bogus.

--joanie

On 10/09/2015 08:24 AM, kendell clark wrote:
hi all
As some of you might or might not know, gnome 3.18 has just hit the
manjaro's unstable repository. Since I'm responsible for building sonar,
I'm usually hit with the latest bugs ... err, I mean fixes, before new
images come out. I decided to try gnome running under wayland since the
changelog indicated "lots of improvements". There are a couple of
accessibility bugs I noticed right off the bat. Two of them having to do
with orca and one not. First, the orca ones. Orca doesn't seem able to
access applications that utilize qt, either 4 or 5. I've tested this
with vlc media player, qt4, and mumble, qt5. I also tested with rockbox
utility, just in case the version of mumble I was testing with still
uses qt4, I'm not sure whether official mumble uses qt5 just yet. Orca
says simply "window" and can't access any of the application's menus or
dialog boxes. Orca also seems to easily lose focus on applications when
you alt tab away from them. In wayland, when you alt tab back to an
application, usually orca will not be able to interact with the
application. Typed characters will read but orca can no longer navigate
in text fields. Tested with gedit. I'm not certain if this one is a bug
or not, since it's sort of intermittent. Those are the orca bugs I've
noticed so far but I'll keep testing in wayland. That's my next to do
task, to get all of the accessibility bugs in wayland squashed, and
there really aren't that many. Now for the non orca related bug. I've
been using chrys's ocrdesktop for months now and it's fantastic.
However, it doesn't seem to run under wayland. It does, however, run
under x just fine. When attempting to run it from a terminal, the output
I get is this:
sys:1: PyGIWarning: Atspi was imported without specifying a version
first. Use gi.require_version('Atspi', '2.0') before import to ensure
that the right version gets loaded.
Traceback (most recent call last):
  File "/usr/bin/ocrdesktop", line 1331, in <module>
    Application = OCRScreenReader()
  File "/usr/bin/ocrdesktop", line 757, in __init__
    if self._Navigation._screenShot():
  File "/usr/bin/ocrdesktop", line 169, in _screenShot
    Ok = self._screenShotWindow()
  File "/usr/bin/ocrdesktop", line 125, in _screenShotWindow
    currWnckScreen.force_update()
AttributeError: 'NoneType' object has no attribute 'force_update'
I don't understand any of that, but a crude guess would be something
ocrdesktop is depending on doesn't work well in wayland. I've tried
uninstalling and reinstalling ocrdesktop just in case the huge gnome
update broke it, but no luck. One last thing I think should be fixed
asap, but I can't really help fix it other than suggestions. In gnome
3.18 gnome switched from having progress dialogs for big operations,
moving, copying, deleting, etc and instead shows progress bar info in
the ... is it the header bar? The tool bar? As of now, orca cannot see
or read these, and this needs to be fixed. Otherwise a person is likely
to move a large file and then sit there and wonder why nothing is
happening.  In fact, The only reason I didn't fall victim to this is
because I could visually see a pop up in the bar at the top of the
screen, but couldn't read it. I'm not certain if this is a gnome bug or
an orca one.  The only reason I'm mentioning this is because while the
operation is taking place, you can't get access to the information. Once
it's complete, an item shows up in the menus for undoing, but not while
it's in progress. I'll keep testing and report any more bugs I find.
Apologies for my irritation, My fiance's box just auto installed windows
10 and now I have to completely reformat and re-install, from scratch,
her backup copy I had got infested with something, so it's useless. Sigh.
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
Log bugs and feature requests at http://bugzilla.gnome.org




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]