GNOME Bugzilla – Bug 442083
Orca skips over empty entries with Up/Down Arrow in Firefox
Last modified: 2008-07-22 19:27:28 UTC
From the Bart on the Orca list: > A quick question, has anyone noticed that with the google homepage > when you arrow down from the top Orca speaks "text" for the search box > and you can enter search queries. If however you arrow up through the > page the text box appears to be skipped. > > It works fine again if you arrow down to it or if you use orca plus > tab to navigate between form controls. This is confirmed.
Created attachment 89251 [details] test case Google is just one example. It seems that if the entry is at the beginning of the line we miss it going down but catch it going up. Similarly, if it is at the end of the line, we catch it going down and miss it going up. Note that contrary to the appearance of Google, the entry is at the end of the line: There's a table cell with a single non-breaking space on its left. Also note that this only seems to happen if the entry is empty. Typing a single character in the entry is sufficient to stop the problem.
Created attachment 89252 [details] [review] patch to hopefully solve the problem The problem seems to be in findPrevious{Next}Line. We cross a line boundary and move to the line with the entry. The entry is empty. The currentChar == "\n", the previousChar != "\n", so we keep on keepin' on. If the currentChar == "\n", the previousChar != "\n" and we happen to be at an entry, we should also set crossedLineBoundary to True. Mike please test. Will, thoughts?
I just spoke with MIke. This doesn't solve the issue on his personalized Google page (google.com/ig). I'll look at that now.
> Mike please test. Will, thoughts? I think it looks OK, though it surprises me that a single line entry would have a "\n" in it. That seems like a Gecko bug to me, or am I missing something?
> I think it looks OK, though it surprises me that a single line entry would have > a "\n" in it. That seems like a Gecko bug to me, or am I missing something? Hmmm.... I'm not sure. It feels intentional. The "tag BR" attribute disappears the minute you type text in there and returns if you delete that text. If there weren't any characters (including the line break) in the entry, would we still be able to arrow into it? If that's not an issue, I will file a bug. I would just hate to ask for it to be removed and then discover that we wanted it back because it was buying us something we didn't realize. What do you think?
> Hmmm.... I'm not sure. It feels intentional. The "tag BR" attribute > disappears the minute you type text in there and returns if you delete that > text. Interesting. An entry ends up getting a "BR" tag? Does that mean what I think it means (the equivalent of a <br>)? If so, this seems really strange. > If there weren't any characters (including the line break) in the entry, would > we still be able to arrow into it? If that's not an issue, I will file a bug. Ha. I'm not so sure about how our navigation model would handle it. I was just thinking in terms of consistency with GTK+ entries. I'm pretty sure single line GTK+ entries don't give us "\n" characters. > I would just hate to ask for it to be removed and then discover that we wanted > it back because it was buying us something we didn't realize. Me too! Maybe we shouldn't squawk?
> Interesting. An entry ends up getting a "BR" tag? Seems that way. Here's my theory: - With Firefox's caret browsing, you cannot arrow to things that don't have text. As an example, try to arrow to a push button. You can't: The text on the push button isn't actual text, but rather the item's value. - A user who prefers the keyboard over the mouse might want to be able to arrow into an entry. Therefore we need the entry to have text. Of course the entry is empty. The addition of a line break character gives us the text we need while giving the entry the appearance of being empty. Seems sufficiently harmless.... - Because it's a bad idea to mess with form content and/or because the addition of a single character solves the caret navigation issue, remove the line break character if the user inserts a character. Of course, this is just a guess. > I was just thinking in terms of consistency with GTK+ entries. I'm > pretty sure single line GTK+ entries don't give us "\n" characters. That seems to be correct. Then again, users are not arrowing into and out of your typical GTK+ entry. > Me too! Maybe we shouldn't squawk? In light of your "Ha. I'm not so sure about how our navigation model would handle it." comment, that would be my suggestion. :-) I still need to get to the bottom of the issue on google.com/ig. However, if we can count on the coming and going of the line break char in entries, it's predictable and thus something we can deal with. Predictable and deal-with-able are two qualities I like in mainstream software. :-)
Created attachment 89297 [details] [review] only update lineExtents if crossedLineBoundary Mike please test. Will is there any reason why we'd want to set lineExtents to Extents even though we haven't set crossedLineBoundary to True?
Cool! this now seems to work correctly on my personal google.home page.
Mike, will you please do me a favor and read other pages you typically read using Up/Down Arrow? I'm wondering if there is any reason why we'd want to set lineExtents to Extents even though we haven't set crossedLineBoundary to True. While I cannot think of one, and while I've done some additional tests since I posed the question to Will, my fear is that there's something I am not considering.... Thanks!
The only thing odd I'm seeing is that when you open bugzilla.gnome.org and arrow past the search text field you have to arrow up an extra time to get back to the line before the edit. It seems as though you hear the line with the edit twice.
And I suspect it does that even without the patch. Mind checking just to be sure? Thanks! What I believe you are seeing is this: You hear the text that is above the entry (Enter a bug # or some search terms:) Then you down arrow to the line that contains the entry. Focus moves into the entry (as opposed to just moving to the line that contains the entry -- in other words it's just like you tabbed to it or used structural navigation to move there). Because focus has moved into the entry, label guess kicks in. The reverse would be true when arrowing up. If this behavior is not what you would like, please spec out the desired behavior.
Ah you are correct. Lets call this patch a nice improvement
> using Up/Down Arrow? I'm wondering if there is any reason why we'd want to set > lineExtents to Extents even though we haven't set crossedLineBoundary to True. > While I cannot think of one, and while I've done some additional tests since I > posed the question to Will, my fear is that there's something I am not > considering.... Thanks! In looking at the logic, it seems like you're doing the right thing. We should only start building up new extents when we actually do cross line boundaries. I say accept-commit-now and close. :-)
Thanks Will. Committing and closing.