GNOME Bugzilla – Bug 437753
Orca should speak and braille the current locus of focus after a page is loaded in firefox and then start reading the page
Last modified: 2008-07-22 19:27:34 UTC
When a new page is loaded in firefox orca frequently only brailles the load complete message or the page title. This can best be seen when opening slashdot.org. This is not correct behavior. A couple different things should happen here. 1. If the page explisetly sets the focus to a certain location and speech is enabled orca should start a sayall from that point. 2. If no focus is set and speech is enabled orca should start sayall from the top of the page. 3. If only braille or mag are enabled focus should simply be placed and shown at the focus location.
In talking with Mike, we should also just speak/braille the current object/line with focus when one switches page tabs. There's a recent regression in Firefox that might be causing us issues with this: https://bugzilla.mozilla.org/show_bug.cgi?id=382007.
Created attachment 89074 [details] [review] Work in progress This is a work in progress. It doesn't seem to track the caret context very well, though. Something might be getting askew with the caret context -- I think we might need a method to set the caret context rather than setting it directly in code.
Well...the previous patch will speak/braille the current line (I commented out the sayAll while debugging) when you load a new page, I believe. There's also an enhancement in there to purposely not so a sayAll if the initial focus is on an editable object, such as Google's search text. This fails miserably, however, when switching between pages. I believe the problem is that Gecko appears to be giving us a brand new document frame for a page whenever it gets focus again. I'm not 100% sure about this, though. Still investigating.
Created attachment 89083 [details] [review] Revised patch Well...this patch is a little better. It seems to fix bug 433951 more than anything, though. The current behavior with this patch is that the current line will be spoken/brailled when a page is first loaded or Ctrl+Tab'ed to. The automatic sayAll is not working at the moment, however. For some reason, we're failing the check to determine if we're currently in document content. I'll dig some more, though. Mike, if you want to take this for a ride, I'd like input on what the speech should really be doing when you Ctrl+Tab to a page. Plus, I'd also like input on what to do when the initial focus for a page is something that you can interact with (e.g., a text entry). I made it so that say all would not happen in those cases since it seems like you're on a page that's requesting some initial input from you (e.g., google). Of course, say all is not happening at all yet, so no need to comment on that. ;-)
Created attachment 89111 [details] [review] Revised patch that seems to do the trick The main problem was that we were ending up with more than one Python Accessible for the same CORBA accessible for a document frame. We've run into this before, and I'm not sure what's going on since the atspi.py:makeAccessible logic should prevent this from happening. I worked around this by using the _acc field of the object to store the document frame caret context. I'll dig into the multiple Python Accessible problem later -- we may actually just want to live with this problem until we migrate to the pyatspi bindings.
After testing and discussion with Mike and Joanie, I've checked this in. It seems to work OK, but the "Say All" stuff seems to get hung up on these pages: http://www.sfgate.com http://techbargains.com http://live.gnome.org (log out if you are logged in) These *seem* to be problems with the SayAll operation in FF, though. But, I'm not 100% sure so I'm not throwing stones and I'm going to just leave this bug marked as pending.
I agree that it's a problem with Firefox's SayAll. It seems to want to skip over tables and just read the description rather than the table's contents. Toss the stones my way....
From Hermann: sorry for talking back to the team again, but the feature implemented in revision 2438 doesn't work propperly, and I question its usefulness. If there's one thing I really hate in Jaws, it's that automatic reading which you cannot turn off, unless you manipulate the default script. I suggest an alternative: I prefer to hear the number of the main elements, such as links, lists, tables, headings and frames. Unlike some list members I find it useful, since it gives a brief overview of the structure of the page, and it makes searching the page easier, wehn I know that - for example - there are frames or tables, that - maybe - provide information i'm looking for. At the current state of the reading feature Orca hangs in teh first line of the page, but on some pages it reads. I couldn't figure out in the short time why it sometimes reads and sometimes hangs.
(In reply to comment #6) > These *seem* to be problems with the SayAll operation in FF, though. But, I'm > not 100% sure so I'm not throwing stones and I'm going to just leave this bug > marked as pending. New bug opened and patch posted to address the SayAll issue. Please see bug $443067.
A couple of observations: 1. on sfgate.com, when I had disabled my ad blocker, something ad-related moved focus down to the bottom of the page which interrupted sayAll. 2. On techbargains.com reading started towards the end of the page rather than at the top. When I moved focus to the top of these pages, sayAll by sentence worked as expected. So beyond the table problem for which I proposed a patch, it seems there may be a secondary issue around where we start reading when the page loads....
If you disable the "if finishedLoading" line (i.e., make it "if False and finishedLoading"), where does Orca end up thinking the caret is? That is, let the page load, wait for Orca to acknowledge that the loading is complete, and then press the Right arrow key. What does Orca end up presenting at that point?
Just tried it on techbargains.com. It was near the top: On the new lines that precede the "images off" link
I put things back and now Orca's starting the sayAll from the top. I wonder if ads, scripts, whathaveyou are sometimes but not always messing with the focus. Perhaps we should check to see if focus is an an entry (like is the case with search sites) and if not, start the sayAll from the document frame's first child??
(In reply to comment #12) > Just tried it on techbargains.com. It was near the top: On the new lines that > precede the "images off" link Dang. I end up somewhere at the top of the ads on the right hand side of the page. I'll keep digging.
> I put things back and now Orca's starting the sayAll from the top. I wonder if > ads, scripts, whathaveyou are sometimes but not always messing with the focus. > Perhaps we should check to see if focus is an an entry (like is the case with > search sites) and if not, start the sayAll from the document frame's first > child?? I think this might be the right thing to do, since it's so hard to predict why the heck the caret ended up somewhere, with the exception that focus ended up on something requesting some sort of user interaction such as an entry. This does violate Mike's first point in the bug opener though: 1. If the page explisetly sets the focus to a certain location and speech is enabled orca should start a sayall from that point. Mike, what are your thoughts?
To be honest if it's a choice between correct page reading when a page opens and placing the user correctly on the edit field in a search engine for example I'll take the correct page reading. Keep in mind though that the users who don't want auto-page reading aren't going to like this approach.
Mike - just to make sure the understanding is correct: the modified proposal is actually as follows. In most cases do a say all from the top of the page, as opposed to current caret location, which might be sporadic. The exception is when the initial focus is on something like an entry, in which case we would not do a say all.
And the modified proposal is consistent with what Windows screen readers do -- not that it is a justification; merely pointing out that for users making the transition, the behavior will be familiar.
If this is the way we get the most functionality I'm quite happy with this modified proposal.
Created attachment 89254 [details] [review] Patch to implement new proposal This implements the new proposal. Seems to work OK for me. Mike?
This seems to be working really well. I think it should be committed but I'd like to leave it as pending for another day or to just to give it more testing. Wow! we're on a rampage. (smile)
In light of Hermann's observations, would it be worth making the automatic SayAll a setting? It would default to True, but allow users like Hermann to change it. (For what it's worth, on this particular issue I agree with Hermann.)
(In reply to comment #22) > In light of Hermann's observations, would it be worth making the automatic > SayAll a setting? It would default to True, but allow users like Hermann to > change it. (For what it's worth, on this particular issue I agree with > Hermann.) I'm perfectly OK with this. > (In reply to comment #22) > In light of Hermann's observations, would it be worth making the automatic > SayAll a setting? It would default to True, but allow users like Hermann to > change it. (For what it's worth, on this particular issue I agree with > Hermann.) >
Created attachment 89285 [details] [review] Patch to allow user to turn "auto sayall" on and off via preferences GUI (In reply to comment #22) > In light of Hermann's observations, would it be worth making the automatic > SayAll a setting? It would default to True, but allow users like Hermann to > change it. (For what it's worth, on this particular issue I agree with > Hermann.) Done! If auto sayall is turned off, just the first line will be spoken.
Looks good to me. I've tested moving to several pages and the new option seems to work just fine.
Thanks! Closing as FIXED.