After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 543734 - Speech Lags behind in Greedy Cursoring: e.g. FireFox Prefs
Speech Lags behind in Greedy Cursoring: e.g. FireFox Prefs
Status: RESOLVED DUPLICATE of bug 529730
Product: orca
Classification: Applications
Component: speech
unspecified
Other All
: Normal minor
: 2.28.0
Assigned To: Orca Maintainers
Orca Maintainers
Depends on:
Blocks: 491756
 
 
Reported: 2008-07-19 14:25 UTC by Veli-Pekka Tätilä
Modified: 2009-03-17 23:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Veli-Pekka Tätilä 2008-07-19 14:25:21 UTC
I've discovered a fairly serious issue that manifests itself in FireFox but which I believe to be a much more general thing:

Steps to replicate the problem:

1. Go to the FireFox settings by typing in:
about:config

2. Tab to the list of settings and hold down the down arrow key, say for 15 seconds.

Current Behavior:

Judjing by my laptop fan some process starts to eat loads of CPU, Orca responds very slowly an even after I release the down arrow, Orca spends plenty of time still processing my previous input, speaking list item names as it traverses it etc...  The user is definitely not in control here, responsiveness is poor and this behavior makes it very hard to greedily linearly cursor through lists very rapidly. The speech lags behind even worse with Festival (Rab) compared to eSpeak.

Expected Behavior:

The way I'd have expected Orca to work here is as follows. When you press the down arrow, the speech would get instantly interrupted and the next item read in stead. If the screen reader starts badly lagging behind the current focus, it should throw away earlier stuff, rather than naively going through everything and causing the user to have to wait. I know this is much easier said and done, but as a legally blind user, this does matter.

Rationale of expected behavior:

As for the rationale of why linear cursoring makes sense, in addition to searching by substring, this kind of linear walk of a list is a very common search tac to me. It is about the only way I know of quickly getting the big picture of what categories are there in the preference list. That is greedily interrupting the speech so you can tell as fast as possible that OK, there has not been any change at the very beginning of the spoken output.  The same goes with Braille, cursoring down until you feel the setting prefix changing at which point you can read the new category. Here's also an article about blind Web browsing, that happens to touch upon greedy cursoring:

http://www.redish.net/content/papers/interactions.html


Other information:
I'm a MS power user relatively new to LInux and am running Ubuntu 8.04 with the version of Orca and FireFox coming with it on an HP NX8220 laptop. My speech synth is the eSpeak default voice with speed set to max and pitch to min. I also run BrlTTY with Braille Voyager and a custom windowed magnifier at the bottom of the screen at 6x.
Comment 1 Willie Walker 2009-01-15 22:26:40 UTC
We could definitely do better in this space.  I'm marking this as a blocker for the Performance Meta Bug (bug #491756).
Comment 2 Willie Walker 2009-03-17 23:11:12 UTC

*** This bug has been marked as a duplicate of 529730 ***