GNOME Bugzilla – Bug 411261
[pending] Some HTML constructs cause Orca to say just "Link" when arrowing up and down by line
Last modified: 2007-05-01 20:13:32 UTC
Open the given attachment in Firefox. Arrow up and down by line with Orca caret navigation enabled. After you land on a link, the next time you arrow down, the caret will end up at the end of the line and Orca will just say "Link". The caret should instead end up at the beginning of the next line.
Created attachment 83175 [details] Test case
See also http://bugzilla.gnome.org/attachment.cgi?id=83216&action=view for another test case.
With the above test case, it seems that the caret is not actually moving to those links. On my system, I have Orca controlling the caret, but I also have Firefox's caret browsing on. Normally when I move among items using Orca, the visible caret keeps up. With the links in the test case, using H/Shift H or Up/Down Arrow *seem* to cause the link to gain focus: A dotted rectangle is drawn around the link. However, the visible caret remains on the item that had focus rather than moving to the link. When this occurs, Orca does not speak the link. If the link in question already has focus as far as Firefox is concerned (again, as evidenced by the dotted rectangle surrounding it), using H/Shift H or Up/Down Arrow will cause the visible caret to move to that location. When this occurs, Orca does speak the link as expected. Not sure what this means, but I hope it helps. :-)
Created attachment 83333 [details] [review] Patch for the first test case The two test cases are separate issues I think. In the first test case, the issue is that <br> adds a physical newline character into the text. When we get to that character, we notice that we have crossed a line boundary and are setting crossedLineBoundary to True. Then we get the next character (first character on the new line), see that crossedLineBoundary is True, break out of the loop, and leave previousObj as the newline character. Seems we don't want to set crossedLineBoundary to True unless the current char is NOT a newline. This patch takes care of that. Whether or not it's the best way to go about it is something else entirely. :-) BTW, this issue is not limited to links. Take the anchors out so that you have a list (in the non-html sense of the word) of the food types as text. You get the same behavior (i.e. Up/Down moving you to the end of the first).
Nice job Joanie! What happens when there are two <br>'s in a row. Do we end up skipping a blank line instead of announcing it as "blank"?
Oops. Didn't think to try that. Yes, we do end up skipping a blank line. :-(
Created attachment 83342 [details] line break test case Another test case.
Created attachment 83344 [details] [review] revised version of the patch Okay, this patch respects the presence of blank lines that result from multiple, <br>s. I even tried it with 3 <br>s Will. :-) There is one goofy quirk -- which I haven't gotten to the bottom of yet: If you arrow Up/Down in the previous test case file, everything seems to work as you'd expect, namely the caret moves to each blank line (i.e. the second of the two newline characters) HOWEVER, if you then press Control Home and give it another go, the caret moves to the first of the newline characters instead of the second. In both cases, you only move to one newline character. (Thus pressing Control Home doesn't result in Orca moving to and speaking a different number of blank lines; it merely impacts which one gets moved to and spoken.) Why Control Home has this impact is beyond me. If you arrow to the beginning of the first line, or press Home to get there, it doesn't happen.... Brilliant suggestions (and/or snarky comments) welcome. :-)
Created attachment 83408 [details] [review] Patch to hopefully fix the "just saying link" problem Joanie and I sat at my dining room table (which we never use, anyway -- who uses their dining room tables?) and code reviewed this to death. This seems to solve the first problem of this bug. The second problem is indeed a separate bug. We'll leave this bug open for that, though.
Created attachment 84549 [details] [review] handle lines consisting of empty sections in go{Next, Previous}Line I believe I've found another condition that didn't occur to us at the dining room table (which you never use anyway because who, after all, uses their dining room tables?): In go{Next,Previous}Line, currentChar can become None. If this occurs when onSameLine() is False, we set crossedLineBoundary to True because currentChar != "\n". Question is, should we? As an example, go to www.sun.com. Use Up/Down Arrow to navigate around the navbar. As you move from Products to Downloads to Services & Solutions to Support, etc. it takes at least 2 presses of Down Arrow to move from item to item. Orca is silent until it reaches the next item. It seems that in those cases, lastObj (and the entire line) contains a single, empty section (whose role we are not speaking as dictated by _getSpeechForObjectRole()). Mike, does this patch solve the problem you were having? Will, can you think of any cases where currentChar is None and we *do* want to set crossedLineBoundary to True?
Okay, that change causes the unlabeled graphical links under the second "Downloads" link (to the right of "Find and Buy") to no longer be reachable via the arrow keys, so I guess I just answered my own question.... I'll look at this some more tomorrow.
Revisiting this bug, it seems it now covers three issues: 1. The original one posted by Will (test case in comment 1) 2. The additional test case (comment 2) which we subsequently identified as a different issue. 3. The thing I added about what was going on on sun.com. #1 is definitely taken care of. Will, I am no longer seeing issue #2 as I arrow among the contents of slashdot-test.html. Are you still seeing it, or is it safe to assume that this issue is fixed as well? As for #3. What is happening when you arrow from products to downloads (or vice versa) is you land on a character whose extents[1] (i.e. y coordinate) is a negative number. I have a vague recollection of Will saying/commenting that if extents[0] or extents[1] were negative, it was an indication that the character is off-screen. Some brief experiments with window-resizing and accessing off-screen text with Orca leads me to believe that I misunderstood or am mis-remembering: The extents never went negative even when the text was not visible. Regardless.... In go{Next, Previous}Line(), is it valid to set crossedLineBoundary to True when currentChar has a negative extents[1]? If currentChar != "\n" AND extents[1] >= 0, we won't land on a line of nothingness at sun.com. If currentChar != "\n" AND extents[1] < 0, it seems we will. Also doing this check instead of the one proposed in comment #10 does not seem to impact anything else on the page: You can still arrow to the unlableled graphical links that are to the right of "Find and Buy." Patch to follow....
Created attachment 86327 [details] [review] aforementioned patch to (hopefully) handle the issue found at sun.com
The last patch seems simple and correct enough. I say check it in. What's happened with the other patch that's sitting there languishing with a "none": http://bugzilla.gnome.org/attachment.cgi?id=83408
> The last patch seems simple and correct enough. I say check it in. Done. Thanks! > What's happened with the other patch that's sitting there languishing > with a "none": As I recall, you checked it in from your dining room table. :-) I'm updating the status of the patch to reflect that for the sake of closure. :-)
Closing as FIXED.