GNOME Bugzilla – Bug 552887
Orca gets stuck in graphical boxes on websites
Last modified: 2008-10-14 20:26:23 UTC
Please describe the problem: On a lot of webpages, especially newspapers, there are boxes that contain graphics and/or links that point to such graphics or open pages with background information regarding this article. On some of this pages, Orca gets stuck in this boxes: You cannot move out the cursor, and Orca reads the content again and again. This happens when manually moving the cursor by pressing cursorup/down, or when reading the text using the SayAll function set to "read by line". Steps to reproduce: 1. Open for example: http://www.fr-online.de/ 2. Choose a department, I recommend politics (Politik) or business (Wirtschaft) 3. Choose an article, I recommend one on the current financial crisis or the US election campain (Bankenkrise, Finanzkrise) (US-Wahlen, Obama, McCain Palin) Look for such a box and place the cursor there. Try to continue reading after that box. Actual results: The cursor gets stuck in this box. Expected results: To go on reading the article after having read through this box. Does this happen every time? On the mentioned site it happens all the time. I remember that I was able to skip this boxes without problems, so it might be due to a change of the site's design. But I also remember having read such complains by other Orca users for other sites. Other information: No information, but a question: Why do such bugs come up again and again? I think Orca should be robust enough to handle changes on webpages, that are continuously made by the web designers.
> Why do such bugs come up again and again? I think Orca should be robust > enough to handle changes on webpages, that are continuously made by the web > designers. We think it should be that robust as well, Hermann. <smile> As for why these bugs happen in the first place: There are still several Firefox bugs which cause us to be given the wrong information when we ask Firefox for the contents of a given line. It would be nice if the Firefox guys fixed those bugs -- and/or fixed their caret navigation so that we wouldn't have "roll our own." In the meantime, we do our best to try to detect when Firefox gives us bogus line information and adjust accordingly; unfortunately, we don't always succeed (obviously). :-( I'll look into this for 2.24.1 (we're in code freeze at the moment). Thanks for the report!
Hermann, I just tried the steps/cases you described and I cannot reproduce the stickage. The exact stories you mentioned were not present (that I found anyway), but I looked at some other articles. For instance are you getting stuck on this story? http://www.fr-online.de/in_und_ausland/wirtschaft/aktuell/1602021_Prinzipielle-Einigung-ueber-Finanzpaket.html If so, please let me know exactly where. Similarly, I remember your having a problem with images when looking at the content via RSS feed. I'm not getting stuck there. Are you getting stuck on this page: http://www.fr-online.de/rss/wirtschaft/index.xml Again, if so, please let me know exactly where. If you're not getting stuck on either of the above, if you could provide me with the full/direct URL for a page where you are getting stuck that would be great. Thanks!
In the spirit of perseverance I found a page with a graphic where I'm getting stuck. Changing the status back to assigned and hoping that this one case addresses all of the ones Hermann is finding.
Created attachment 119398 [details] [review] The thermonuclear approach The offending hierarchy looks like this: I. Section, which contains: A. Link with line break inside the text with two children: 1. Paragraph with no text other than the EOC for: a. Image 2. Image B. Image C. Link with line break inside the text with two children: 1. Paragraph with no text other than the EOC for: a. Image 2. Image D. Image As a result of this beast, Firefox is issuing caret-moved events left and right. When Orca is controlling the caret and is in a place where it has decided that we should indeed be handling navigation, we don't expect caret-moved events as a general rule and those we do get we expect to be bogus. That said, rather than do a blanket ignore of them, we do a conservative ignore just to be safe. The bogus events resulting from the above hierarchy are sneaking past our conservative check and telling us to move the caret earlier on in the page. This is why we're looping. This patch, as described, is a bit of a thermonuclear approach: If we're in a place where we're assuming no caret moved events and we get some, and the locusOfFocus is either an image or a link, we'll conclude bogusity. Pros: 1. Solves the stuckage problem -- the one that I was able to reproduce. 2. Passes all of our existing regression tests. 3. Passes manual testing in Yelp (we still need to write tests for that). Cons: 1. It might break the same-page-link handling -- were it not for the fact that the Firefox guys already broke that for us. :-( See my last comment on bug #544771. Seeing that same-page links should be fairly predictable (once we're getting the events we should be getting), my recommendation is that we special-case same-page links rather than try to special-case every instance of stuckage as it comes up. 2. For every regression test I write, there are undoubtedly thousands upon thousands of cases I'm not testing. This patch, therefore, needs the bajeezus beaten out of it. I would hate to discover that this solution breaks more than it fixes -- and I'm sure y'all feel the same way.
The patch does not solve the problem, however, it solves another minor one: See: http://www.fr-online.de/in_und_ausland/wirtschaft/aktuell/1601930_Die-grosse-Glaubenskrise.html After the heading of the article, there's an image link, which lead to skip the first line of the article; this now is gone. The image link gets skipped. However: Within this article, there's such a box - or what it looks like - saying: "Vidio Nachrichten" ("video news"). That's where I get stuck even after the patch. It used to work in earlier Orca versions, but unfortunately I cannot say since when It is broken. In my daily work I use text Linux on my GRML machine.
I want to add some principle comments on this: Since such issues come up again and again, literally thousand times, we should think about handling the caret mode completely new: Even if I stress your nerves more than needed, you should think of a kind of reading mode, to avoid the disliked "virtualisation". But I think we can be able to work around this, if we succeed in implementing a mode, for reading a page only, in which it can be reformatted in order to be read more fluency. Maybe it is useful to suppres disturbing images etc. Of course it should be optional. For those, who use the internet to do a lot of reading, this might be a useful addition. If you oppose it, so what can be an alternative? I feel you finally end up in a nervous break down when you have to fix and fix and refix etc. etc. :-(
Created attachment 119562 [details] [review] revision 2 Thanks for the additional information Hermann. I can reliably reproduce the problem using the "Vidio Nachrichten" graphic. This patch solves the problem for me. Please test. Thanks!
Thanks a lot, now it works. I hope we are through with this. The question remains: How can we avoid such issues in the future? (see my last comment). Web designers change their pages all the time, and this is especially true for the FR people.
> Thanks a lot, now it works. Thank you for testing! Patch #2 committed to trunk. Sadly, it doesn't solve the problem I found with the extra caret-moved events and the goofy hierarchy. Therefore I've un-obsoleted my thermonuclear patch and am tossing it back out there for testing and consideration. Will, do you have thoughts on it? > I hope we are through with this. See previous paragraph beginning with "Sadly." But I think we're getting closer to being through with this. <crosses fingers> > The question > remains: How can we avoid such issues in the future? (see my last comment). Web > designers change their pages all the time, and this is especially true for the > FR people. Well.... We can continue to try to detect/predict the oddities that arise, continue to "beef up" our regression tests so that we don't break things down the road and so that we can quickly spot changes in what the FF guys are doing, continue working with the FF guys to get the FF bugs resolved, and continue working with users such as yourself who are willing to live on the bleeding edge, do testing, and file bugs. Beyond that.... The "reading mode" is an interesting idea -- and one I will leave to the project lead and UI lead to comment on. After all, I'm just a volunteer community contributor who's doing her best. <smile>
(In reply to comment #9) > Therefore I've un-obsoleted my thermonuclear patch and > am tossing it back out there for testing and consideration. Will, do you have > thoughts on it? It looks OK to me, but I really don't know this area of the code as well as you. > > I hope we are through with this. Unless mainstream developers test their applications for accessibility and prevent regressions, I'm not sure we will ever be through. I wish, for example, that I could say that a crucial bridge that the Town of Hollis has been working on for the past several months would be solid and fixed by now. Unfortunately, an unexpected rainstorm washed it out and they had to start over again. Nobody is happy. Sometimes, working on accessibility feels that way. All I can say is that we keep working on it, and we also try to keep influencing mainstream developers to increase the care they take in accessible design and to increase the amount of testing they do. BTW, my opinion that FF should be providing reliable and predictable caret navigation still stands. I often wonder if we might have saved a lot of time if we ramped up an effort to fix caret navigation closer to the source (e.g., a Firefox extension or mucking in the deep, dark, internals of the Firefox navigation code itself). > edge, do testing, and file bugs. Beyond that.... The "reading mode" is an > interesting idea -- and one I will leave to the project lead and UI lead to > comment on. After all, I'm just a volunteer community contributor who's doing > her best. Can you describe how this 'reading mode' might work? For example, how would you interact with it (e.g., braille, speech, keyboard, etc.)?
I had a feature in mind, I saw in the Windows webtool Webbie, a kind of satellite to the IE. See: http://www.webbie.org.uk You have a function called "crop the page". It means, that all non-text elements get stripped by a keystroke, which is a toggle button. When activated, you see only , or almost only, text on the pages. There might be some image links with tags, so that the tags are shown. Rethinking this however, leads me to the question whether this should be an Orca feature, or a FF extension? I remember of an extension called Greasemonkey, which allows changing the pages outfit by using Java scripts. But this approach seems to me a rather professional one, so that it can be hardly handled by ordinary Linux users. The only solution for using Greasemonkey would be, that someone can provide some useful standard scripts that can adjust the page to show text only. But unfortunately I cannot write Java scripts. So how can we go on?
(In reply to comment #11) > I had a feature in mind, I saw in the Windows webtool Webbie, a kind of > satellite to the IE. See: > http://www.webbie.org.uk > You have a function called "crop the page". It means, that all non-text > elements get stripped by a keystroke, which is a toggle button. > When activated, you see only , or almost only, text on the pages. There might > be some image links with tags, so that the tags are shown. > Rethinking this however, leads me to the question whether this should be an > Orca feature, or a FF extension? I try to lean towards pushing things closer to the source than doing tons of customization in Orca. The benefit of doing things this way is improved performance and it also usually ends up in more than one disability category benefiting from the work. It seems like the example you describe (i.e., WebbIE) is a possibility for a FF extension. It looks like one of the cool things that might come out this would be a drastically simplified "flat text" form of the web page that should be very amenable to even FF's keyboard navigation scheme. Greasemonkey might be an option, though I admit I know very little about it except that the stuff I've seen was pretty cool. It was also dead simple to install and enable, but I only used other people's scripts and never wrote my own. For where to start? Well....you need to find a capable programmer with spare time. That's the hard part.
Reassigning back to me to deal with the other stuckage issue listed in this bug. Will I assume you don't mind. :-)
Joanie, in a former comment you wrote: "Sadly, it doesn't solve the problem I fo and the goofy hierarchy. Therefore I've am tossing it back out there for testing thoughts on it?" Can you give an example for this? (sorry for my ignorance, but I might have missed something). Does it happen on FR pages? Do yu refer to the graphics placed after the article's headline? If this is what you mean, then the issue is solved: The article's text start after the graphic, however in the same line. The issue in the RSS-page has been solved a while ago and never came back *knok on wood*
(In reply to comment #14) > Can you give an example for this? Yup, you just have to keep arrowing on the page you suggested, or many of the article pages it seems. Eventually, about half way down the right-hand sidebar, you'll find "Fotostrecken Wirtschaft" followed by an image ("Bankenmischmasch") followed by "Banken - Die Karten werden neu gemischt". I cannot get past this without the thermonuclear patch.
I've tested this, and I can confirm, that one needs the patch. I reversed it, and got stuck at the very point. So it should be checked into Orca's code.
Thanks so much for testing Hermann! Given its thermonuclear nature, before I check it in, would you mind continuing to use it for a couple more days just to be sure that it doesn't break anything on some other site which I didn't think of? Mike and Jon if you could do likewise that would be awesome. Thanks guys!
> Thanks so much for testing Hermann! Given its thermonuclear nature, > before > I > check it in, would you mind continuing to use it for a couple more days > just to > be sure that it doesn't break anything on some other site which I didn't > think > of? Mike and Jon if you could do likewise that would be awesome. Thanks > guys! OK, I'll test it for the next few days, since I need it to read my newspaper with Orca. Till now I didn't find anything that has been broken by that patch, but this has to be watched for a while.
If Hermann has no further issues with this patch I'm good with it as well.
Created attachment 120242 [details] [review] kinder, gentler version of the thermonuclear patch I finally tracked down the build in which the Firefox guys broke same page links for us (the caret-moved event for the anchor went AWOL 17 Sept). As a result, I was able to modify the patch so that it doesn't break the same page link functionality (once it's restored). * Still solves the stuckage the first version fixed. * Pylinted and re-regression tested. Based on Mike's findings and not hearing any negative side-effects from Hermann, I have committed this version to trunk and will move this bug to pending.