GNOME Bugzilla – Bug 413253
Orca cannot Up/Down Arrow past images that are links
Last modified: 2007-03-02 20:44:30 UTC
In the test case (to be attached), use Up/Down Arrow to navigate the page. Orca will get stuck at the image which is also a link. If you remove the anchor, Orca does not get stuck.
Created attachment 83598 [details] aforementioned test case
Created attachment 83664 [details] [review] proposed patch Will, it looks like we only code reviewed the solution to bug #411261 into a coma. :-) With the test case in question, we get just past the text and head for the image when along comes this error: Traceback (most recent call last):
+ Trace 114973
consumed = self._function(script, inputEvent)
obj.text.getText(characterOffset, characterOffset + 1)
If we actually check for obj.text before trying to use getText, we don't get the error or stuck.
Created attachment 83668 [details] [review] corrected version Oops. Just because we don't have text doesn't mean that the following won't be the case: if extents != (0, 0, 0, 0): if not self.onSameLine(extents, lineExtents): if not crossedLineBoundary: Need to set currentChar to None outside of the while loop.
Created attachment 83677 [details] [review] hopefully the final version :-) As Will pointed out, if there's no obj.text, previousChar should be None. With any luck, 3rd time is charm.
There seems to be another side effect of the solution to bug #411261 (as originally implemented) or in the above patch. If you navigate up and down in the text towards the bottom of http://www.kurbad.nu/ *without the fix or patch*, things work as expected. With the fix or the patch, arrowing down works as expected, but arrowing up causes some lines to be skipped.
Created attachment 83682 [details] test case to illustrate the problem from the previous comment With the patch for 411261 -- whether or not you use the patch for this bug -- you can arrow down as expected through all of the text. When you up arrow things work as expected everywhere *but* within the text that is formatted to be small. Without the patch for 411261, this doesn't happen.
Ahh...good find. This might be related to the onSameLine hackery.
Possibly, still trying to figure that out. Here's a weird discovery (at least I think so): If you up arrow through the small text, Orca will skip over things UNLESS you move focus to a different window first. If I do Up Arrow, then Alt Tab to another window, then Alt Tab back to Firefox, and then Up Arrow, no text gets skipped.
If you press Ctrl+= to enlarge the text, the problem seems to go away. I'm still going to say onSameLine is a suspect. ;-)
Funny, I was just doing the same thing (enlarging the text). A couple of samples going from the line that says "You get the idea" and arrowing up once: ----------------------------------- With the text tiny: Current char: Y, Previous char: (space), extents[1]: 261 Current char: \n, Previous char: t, extents[1]: 258 At this point, onSameLine is False. But the current char is \n so we don't set crossedLineBoundary. Current char: t, Previous char: x, extents[1]: 248 AND: onSameLine returns True. :-( ----------------------------------- Press Control+=: Current char: Y, Previous char: (space), extents[1]: 281 Current char: \n, Previous char: t, extents[1]: 278 At this point, onSameLine is False. But the current char is \n so we don't set crossedLineBoundary. Current char: t, Previous char: x, extents[1]: 266 AND: onSameLine is once again False, and the current char is not \n so we set crossedLineBoundary.
Created attachment 83696 [details] [review] another correction This is what I get for saying "hopefully the final version".... If obj.text and the characterOffset == 0, we need to set previousChar to None. (This has nothing to do with the tiny text/onSameLine issue; just making the correction before I forget.)
w.r.t. moving focus away from Firefox and then back with Alt Tab and the problem seemingly going away: In that instance we're not using goPreviousLine() for the initial press of Up Arrow. I'm not sure if that's a bad thing (i.e. if Orca is controlling the caret, shouldn't it do so when the window first (re)gains focus?) or just a thing. :-)
Created attachment 83749 [details] [review] includes a hack for the tiny text issue Before text was deemed to be on a different line if there was no overlap whatsoever between the lowestTop and the highestBottom. Now we're allowing an overlap of 1 pixel or less in order to solve the problem of really small text being skipped when navigating by line.
The patch has been checked in.
Closing as FIXED.