Closed Bug 371941 Opened 14 years ago Closed 14 years ago
Caret Position on first character of a line puts the caret at the end of the previous line
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070222 Minefield/3.0a3pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070222 Minefield/3.0a3pre Something seems to be wrong with the implementation of setCaretPosition. When Orca attempts to set the caret position at the first character of a line in a paragraph, the blinking caret ends up at the end of the previous line. Reproducible: Always Steps to Reproduce: 1. Run Firefox. Open http://live.gnome.org/Orca 2. Run Orca v2.17.92 and give the Firefox window focus. 3. Press Insert+F12 until you hear Orca say "Orca is controlling the caret" 4. Press Ctrl+Home 5. Scroll Firefox to the first paragraph on the page. Position the caret between the 'p' and 'e' in the phrase "people with visual impairments". You'll probably have to use the mouse for this (unfortunately). 6. Press down arrow. Actual Results: The caret ends up at the end of the current line instead of the beginning of the next line. Press right arrow now. You'll see that the caret jumps to the second caret on the line. Expected Results: The caret should end up at the beginning of the next line. I've debugged this quite a bit, and I'm pretty sure Orca is telling Gecko to position the caret at the right spot. In addition, this sometimes works if you load the page and don't press Ctrl+Home.
I think this is because Mozilla has two different ways to show the caret is before the "d" below: abc def The caret can either be shown before the d or at the end of the line "abc " (after the space/newline char). That's bug 347494. At the time it was done it was thought to be a good idea, because the end key would go to the end of the line visually. Anyway look at the bug but I don't see that behavior in modern editors, so I'm hoping we can get that fixed. It means the same character is actually in the right arrow sequence twice. We could devise a workaround solution uf bug 347494 isn't going to be fixed for Firefox 3.
The issue is cross platform and can be reached via the internal nsIAcccessibleText::SetCaretPosition().
OS: Linux → All
Hardware: PC → All
I think we can reduce the test case to this: abc\ndef Visually, and according to the AT-SPI extents of the text, I believe we currently see the following (where the '\n' is not visible, but the AT-SPI extents seem to tell us the '\n' is a 1 pixel square object on a new line): abc \ndef If one positions the caret at the offset for '\n', then I'd agree it should end up at the end of the 'abc' line. If one positions the caret at the offset for 'd', however, I think it should end up at the beginning of the 'def' line. Thanks! BTW, if you decide to change the extents of where \n ends up, please let us know. Some of our logic depends upon the current behavior.
This looks a lot like bug 334256 (fixed on trunk). You're testing on trunk, right? One issue might be that the fix for bug 334256 was subsequently (bug 338315) limited to the "normal" selection. Perhaps a11y uses a different selection? bug 347494 is specifically about textareas (-moz-pre-wrap), so I'm not sure it's relevant here. Also, I don't understand whether the problem here occurs with a wrapped line (no \n), or at a hard line break. Also, I couldn't find a SetCaretPosition() anywhere - perhaps you mean SetCaretOffset()?
> This looks a lot like bug 334256 (fixed on trunk). You're testing on trunk, > right? You're right. Looks like the automatic update download stuff in FF has been broken for a while. and I didn't notice it wasn't working any longer. :-( When I grab the latest tarball, the problem seems to go away. Yeah! Thanks for the fix! > Also, I couldn't find a SetCaretPosition() anywhere - perhaps you mean > SetCaretOffset()? Sorry. Yes, setCaretOffset. setCaretPosition is the wrapper we have to have around it in Orca to make sure we give the right object focus first.
(In reply to comment #5) > When I grab the latest tarball, the problem seems to go away. Yeah! Thanks > for the fix! np. => WORKSFORME
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.