Open Bug 347494 Opened 18 years ago Updated 4 years ago

In textareas, moving the caret accross a wrapped line requires an extra press of the right/left key

Categories

(Core :: DOM: Selection, defect)

Product:
Core
Component:
DOM: Selection
Type:
defect

Tracking

()

People

(Reporter: uriber, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Moving the caret across the point where a line wraps in a textarea requires an extra press on the left/right arrow keys, which doesn't actually move the caret logically, bug just moves it visually from the end of the previous line to the beginning or the next one (or vice versa). Steps to reproduce: 1. Type a line of text which is long enough to wrap into a textarea (such as in this bug). 2. Place the caret at the end of the first line, after the last space. 3. Press right-arrow. Notice that the caret moves to the beginning of the second line, but is logically still at the same place - between the space and the next word. 4. Now press left-arrow. The caret returns to its original position, but, again, it remains in the same logical place. This behavior was apparently implemented on purpose (as part of bug 9195). It was requested (or at least its "forward" part was) in bug 9433 which said: "[Pressing the right arrow when after the space at end of a wrapped line] should move [the caret] to the beginning of the [next] line (just before the first character.) This is tricky since technically, this is not a change in location, but it is what should happen in any word processor." While that might have been true for 1999-era word processors (I doubt it), a quick survey done by aaronlev (on various Windows apps) and me (on Mac apps), shows that no other browser or editor displays this behavior. The behavior I see on Mac apps is: When the caret is placed before the last space on the line, and right-arrow is pressed, the caret moves immediately to the beginning of the next line. pressing left-arrow now moves the caret back to its original position, between the last word on the previous line and the following space. Apparently this is also the current Mozilla behavior in the HTML editor.
Blocks: keya11y
I'd like to wait with this until after (some version of) my patch for bug 300131 goes in.
Depends on: 300131
No longer blocks: 344423
Blocks: fox3key
No longer blocks: keya11y
Blocks: texta11y
Keywords: access
I think this also causes bug 371941.
This is confusing JAWS. When the user moves the caret JAWS needs to speak the line. Here's the algorithm JAWS uses: 1. Get offset in to the text for caret 2. Get the line of text for that offset Since the offset for the caret is on the char that starts the next line, it ends up with the line of text after the caret, not at the caret, and speaks the wrong thing.
Blocks: fox3access
Right now I'm looking at JAWS with Notepad, Wordpad and Microsoft Word 2003. This is for the scenario where text wraps to the next line. 1. If you hit End, you're past the last char of the line. You're really on the first char of the next line. Although visually you're on the same line, logically you're on the next line, because the delete key will delete the first char of the next line, and right arrow will go to the 2nd char of the next line. 2. If you right arrow through a line, you never reach that final position where you're past the end. When you're on the space for the end of the line, the next right arrow key brings you to the next line. 3. This means that if your press End. left arrow, right arrow you change lines! 4. If you press the end key, then right arrow you won't hear the first char of the line you've moved to 5. If you press up or down arrow and you're near the end of a long line, you can end up past the end-of-line space char if you've moved to a shorter line. Logically you haven't changed lines, only visually. Guess what JAWS does for this scenario -- it reads the wrong line sometimes! - it always reads the wrong line in Wordpad - it reads the wrong line if you move down in Word 2003 - it always reads the right line in notepad Not sure if fixing this bug will really help JAWS, because users will still expect the End key to work the same way that it does now. I believe the proposal would be to make things work as it does in Wordpad, Notepad and Word. The right arrow after the End would take you to the 2nd char in the line.
Hmm, it seems like the thing to do is make up/down from put the position at the end-of-line char, not after it. IOW, unless the End key itself is actually used, the max caret position we move to should be to the end-of-line char, not after it. Only the end key should be allowed to do the weird behavior. MS Word does that most of the time, but I was able to sometimes get up/down to put me visually on one line and logically on another.
Uri, in comment 1 you said you'd like to do this after some version of your patch for bug 300131 was checked in. It has been ... can you look at this now?
Sorry, Aaron, but I'm afraid I don't currently have time to get back to this, and I likely won't have time to do this anytime soon. :-(
Turns out that many programs on Linux don't have this problem. The End key puts you at the space/newline char for the soft line break. For example, gedit, Opera and Open Office do it that way.
Uri, I could try and look at it if you have any ideas of how to do it, and have time to throw some hints out.
Uri, I propose something different from what you suggest in the description: > Not sure if fixing this bug will really help JAWS, because users will still > expect the End key to work the same way that it does now. I believe the > proposal would be to make things work as it does in Wordpad, Notepad and Word. > The right arrow after the End would take you to the 2nd char in the line. I propose we act more like Opera, Open Office and GEdit. In those programs the end key puts the caret before the space on a wrapped line. The next right arrow key goes to the first char on the next line. That's most intuitive to me. If you want to select the entire line including the space and the end you can use shift+down or shift+end then shift+right. BTW, I never did find the checkin from bonsai that made this change.
Isn't there the case of a consecutive block of non-whitespace that is longer than a single line? There won't be a space at the end because the word would be broken in the middle. This doesn't appear to happen in a web browser (although I'm not certain that it can't happen). However, a word processor would break the long "word" in the middle.
Bill is right. In that case OpenOffice puts the caret past the last char in a line, and the next right arrow moves to the 2nd char in the next line.
(In reply to comment #10) > Uri, I propose something different from what you suggest in the description: > >> (snip) > > I propose we act more like Opera, Open Office and GEdit. In those programs the > end key puts the caret before the space on a wrapped line. The next right arrow > key goes to the first char on the next line. That's most intuitive to me. If > you want to select the entire line including the space and the end you can use > shift+down or shift+end then shift+right. > > BTW, I never did find the checkin from bonsai that made this change. > Sorry for not responding earlier. Couple things: - This bug is only about the behavior of left/right arrow keys, not about the behavior of End. If you want to change what "End" does, I suggest submitting a separate bug. - I don't see how what you're proposing is different than what I suggested: > When the caret is placed before the last space on the line, and right-arrow > is pressed, the caret moves immediately to the beginning of the next line. - I can't find the original checking either, now. I'll try again later.
Assignee: selection → nobody
QA Contact: selection

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5

This issue is not trivial, nor cosmetic. It does impact users. It especially impacts Thunderbird users working on emails, which are mostly plain text - and area for that text is impacted by this issue.

Also, it is worth noting that Mozilla's current approach also involves making the movement over the space character between two words, at which a line breaks, behave as a caret move on the same line, while in other editors - it's the movement over the space itself which moves the caret to the next line. So when this is fixed, it should not be fixed in a way where pressing right (in an LTR paragraph) twice moves you first to one-space-past the last word, then again to the second character on the next line; it should be a single press moving you from the end of the last char of the last word on the first line, to the first char of the next word on the next line, traversing the space and the automatic line break at once. That is as though the space was a line break. That's the common behavior today and it makes sense.

Severity: S4 → S3
Priority: P5 → --

Hi Wayne, maybe this fell off our radar and impact seems to be mostly on Thunderbird users.

Flags: needinfo?(vseerror)

and impact seems to be mostly on Thunderbird users.

I didn't say that... The impact is whenever a textarea is used to edit multi-line text.

I agree, S3 is appropriate.

Flags: needinfo?(vseerror)
You need to log in before you can comment on or make changes to this bug.