GNOME Bugzilla – Bug 423435
[verified] Orca is too chatty when loading a page in Firefox
Last modified: 2008-07-22 19:27:19 UTC
When it takes a long time to load a page in Firefox, Orca outputs a bunch of chatty information that is irrelevant and confusing (e.g., it sometimes speaks the name of the current window over and over) before finally saying "Finished loading." This chattiness should be reduced to relevant information only.
A possible solution to this might be to maintain some sort of state (i.e., Gecko is currently loading a web page) and prevent speech/braille from being updated during this time. This might be a terrible hairball if we want to globally prevent speech/braille. A more isolated approach might be to see what kinds of events we are getting while a page is loading and selectively filter on those.
I did some digging into this to see what events were being delivered between the time I caused Firefox to want to go somewhere (e.g., activate a link, enter a URL, etc.), and the time the page was ultimately loaded. I'm seeing the following important events that cause us to speak information in between the "Loading" and "Finished Loading" messages: OBJECT EVENT: focus: detail=(0,0) app.name='Minefield' name=None role='document frame' state='BUSY ENABLED FOCUSABLE FOCUSED HORIZONTAL OPAQUE SENSITIVE SHOWING VISIBLE' relations='' SPEECH OUTPUT: 'http://bugzilla.gnome.org/attachment.cgi?id=85866&action=view html content' OBJECT EVENT: object:state-changed:focused detail=(1,0) app.name='Minefield' name='http://bugzilla.gnome.org/attachment.cgi?id=85866&action=view' role='document frame' state='BUSY ENABLED FOCUSABLE FOCUSED HORIZONTAL OPAQUE SENSITIVE SHOWING VISIBLE' relations='' SPEECH OUTPUT: 'Google page' OBJECT EVENT: object:visible-data-changed detail=(0,0) app.name='Minefield' name='Google - Minefield' role='frame' state='ACTIVE ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE' relations='' Notice that during this time, the document frame marks itself as having STATE_BUSY. This might be a useful indicator for us somehow. In particular, we might attempt to ignore focus events on the document frame while it is STATE_BUSY, and we might also ignore visible-data-changed events on a frame if the document frame is STATE_BUSY. I'll hack unless someone else beats me to it.
Created attachment 88016 [details] [review] Patch to reduce chattiness
Created attachment 88020 [details] [review] Revised patch based upon communication with Aaron Leventhal
Created attachment 88027 [details] [review] Revision on first patch This patch is a variant on the first patch. It turns out that acting on the document load-completed event is too soon since the title of the window hasn't been updated yet. If we wait until the busy state clears (the second time), things seem to be stable and we can present them.
This is working much better. Should I file a separate bug for pages that don't update the braille focus correctly? I think this has to do with weather or not firefox places focus correctly in the document or not.
(In reply to comment #6) > This is working much better. Should I file a separate bug for pages that don't > update the braille focus correctly? I think this has to do with weather or not > firefox places focus correctly in the document or not. I think there are two different additional bugs: 1) Once a page is loaded, also present the current locus of focus on the page (if it exists) in both speech and braille. If Firefox didn't give anything focus in the document, should we set the locus of focus to the first thing on the page (I guess) and present that? 2) You mentioned something about navigation of menus and the autocomplete URL location bar causing spurious speech output.
> 2) You mentioned something about navigation of menus and the autocomplete URL > location bar causing spurious speech output. w.r.t. the location bar, there are a couple of things going on which I noticed while working on the solution to Find support: 1. The location bar seems to have acquired an ancestor of ROLE_UNKNOWN. This occurred a few days ago. Who knows why? Haven't had time to ask yet. 2. getSpeechContext() was frequently "bubbling up" the hierarchy to the application frame, I took a stab at handling both issues in my Find patch (bug 407663), so Mike when you are trying the Find stuff, please also check the address bar chattiness. Thanks!
OK - I'm closing this as FIXED. The problem of not speaking the current object with focus in a new page is tracked in bug 437753, and the spurious speech problem might be fixed in bug 407663. If the spurious speech problem is not fixed with bug 407663, then a new bug should be opened.
Reopening -- the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=381832 hurt this logic. Patch coming soon.
Created attachment 89018 [details] [review] Patch to work with new FF behavior (FF from 29-May) The new behavior of FF simplifies the amount of work we need to do in Orca.
Committed. Mike, please test -- you'll need a FF from at least 29-May.
I've tested this while moving between lots of web pages and it seems to be working well.
Thanks! Closing as FIXED.