GNOME Bugzilla – Bug 592383
Orca gets stuck when it encounters a paragraph in Firefox which begins with a multi-line-high character
Last modified: 2009-11-09 21:35:18 UTC
When using orca with firefox (with orca controlling the caret) it is possible on some websites to meet certain points where orca will not move down a line when the down cursor is pressed. Also sometimes when this occurs (always happens on the pages when it happens, always does for the example used to reproduce) the line at which orca gets stuck is not completely read. How to reproduce: This is using orca 2.27.90 on a debian system with iceweasel 3.0.12 (I have disabled webvisum as it has been known to cause some problems). 1. use firefox (iceweasel in my case as using debian) and navigate to http://barryandjanet.co.uk/tandem/brakes.htm 2. Navigate to the section headed "Alternative descent technique for any tandem braking system." 3. press cursor down a few times (eg. 10 is more than enough to show bug is present). Expected: Orca should move down a line every time down cursor is press unless the bottom of the page is reached. Actual: Orca gets to the first line of content of that section and just reads "W" for the line and refuses to move on. Only way to move beyond this with cursor keys is to use the right cursor until you have moved to the next line. I have encountered other websites with similar behaviour from orca, although the failure to read all the line at which orca gets stuck is not so common. The example given seems to always happen when the steps given are followed.
Thanks for filing this Michael! I just took a quick glance. Where we're getting stuck is on initial capital letters which span multiple lines. Taking this one. Whether or not it winds up being fixed for 2.28 will depend upon whether or I can target this case without jeopardizing overall line navigation. As we all know, Orca used to regularly get stuck trying to piece together lines in Gecko; now (as far as I am aware), it doesn't happen all that often. I'd hate to break that right before a major -- and supposedly stable -- release. I'm also going to resummarize this one to reflect the specific issue, which may or may not be the issue on other pages.
Created attachment 141191 [details] [review] possible fix Quick fix in between work tasks.... Pylinted; not regression tested. Yet. I'll run them this evening. Michael could you please give this a spin on the page in question as well as the other pages where you are experiencing problems? Thanks!
Created attachment 141198 [details] [review] same fix, now with regression test I created (and committed) a new regression test for this issue to illustrate the current state of affairs. This patch has the same fix, but includes an update for that regression test.
Unfortunately this patch doesn't seem to resolve it for the example I gave. It does only seem to be the section "Alternative descent technique for any tandem braking system" which is affected on the page (I haven't looked into what is different for that particular line). As for the other examples, one which was big in my mind in fact turns out to be another bug (tab movement gets stuck). I will retry this all tomorrow morning when I can be certain of being fully awake (fairly sure I haven't made a mistake, best to check). (In reply to comment #2) > Created an attachment (id=141191) [details] > possible fix > > Quick fix in between work tasks.... Pylinted; not regression tested. Yet. I'll > run them this evening. > > Michael could you please give this a spin on the page in question as well as > the other pages where you are experiencing problems? Thanks!
That's really odd because I could totally reproduce the problem you describe 100% of the time. The problem is fixed (for me) by that patch. And the regression test (also reproducible, also fixed by the patch) is based on the very case you cite (complete with the 'getting stuck on the W'). Oh well, I guess I fixed another bug that needed fixing. <smile> As for the behavior when Tabbing. If you mean that you press the Tab key and get stuck: Orca doesn't do anything when you press Tab other than speak the object with focus. We assume that navigation by Tab is something that Gecko can handle all by itself. :-) Therefore, unless something really, really bizarre is taking place that would either be a content provider bug (perhaps doing an onFocus blur), or a weird Mozilla bug.
I see what the difference is between my results and Michael's. I am using Firefox 3.5. I just got a copy of Firefox 3.0.12 for OpenSolaris. There, the giant 'W' is exposed as ROLE_TEXT rather than ROLE_PARAGRAPH. My fix is specifically looking for an object of ROLE_PARAGRAPH nested at the beginning of another object of ROLE_PARAGRAPH.
All regression tests passed. Will please review. Thanks! In terms of consideration for 2.28: * Low risk: Nested accessible paragraphs are rare in Gecko. Normally, other texty objects which don't fall into any other category wind up being exposed as ROLE_TEXT; not ROLE_PARAGRAPH. So I believe we're doing a pretty specific check for a pretty rare object/occurrence. * Potential for high impact: This construct reliably causes us to "get stuck." Getting stuck is bad. As for the 3.0.x vs 3.5.x: I *could* broaden the check out a bit to include ROLE_TEXT inside ROLE_PARAGRAPH, but I'm hesitant to do so this close to the 2.28 release because of the increased risk (likelihood of false positives), especially given that the current stable release of Firefox doesn't require that to be done.
Comment on attachment 141198 [details] [review] same fix, now with regression test Looks good. Thanks for getting on this one so quickly.
Thanks Will. Patch committed to master. Michael, could you please try the latest master with Firefox 3.5?
(In reply to comment #9) > Thanks Will. Patch committed to master. > > Michael, could you please try the latest master with Firefox 3.5? I have tried it with firefox 3.5.2 (from the mozilla website rather than the debian repositories) and with the latest orca from git, works (as far as this bug report goes, orca doesn't get stuck). The only comment I will make is that the "W" is separate from the rest of the word "Why". You may not want to see to this as I can imagine that it may be difficult to tell whether spaces really should exist or not. Also I noticed that when using firefox 3.0 it said "text" after the "W" but not with firefox 3.5. I think Joanie explained why, would it be useful for me to mention when orca says "text" after the content if I find and report other firefox bugs?
Thanks Michael. It turns out that the W really is separate. It's followed by non-breaking space characters, added in as part of the markup and exposed as part of the accessible text. But were that not the case, you are correct -- it would be difficult, and error-prone, for us to try to interpret programmaticly when a separate paragraph should be treated as such and when it should not. In other words, it ain't gonna happen I'm afraid. As for mentioning when Orca says "text" after content: Every little bit of information helps. Thanks for asking! Closing this bug as FIXED.