Try typing a few lines in a description field in bugzilla, or in plaintext mailcompose and then move to the beginning for any line except the first line and hit the left arrow key, nothing happens, the cursor should move the the end of the previous line, same goes if you go to the end of any line except the last line and press the right arrow key one would expect the cursor to move to the beginning of the next line, but nothing happens. This is a pathetic regression that should've been caught by pre-checkin tests, but apparently wasn't. Stopship! Must be fixed for rtm! (this is on the trunk, btw, todays nightly build).

removing nsBranch keyword until it is confirmed using a trunk build from 2001062704 on win98, the arrow keys function correctly in plaintext mail compose and in plaintext editor what build were you using and what platform, are you using a debug build or opt build, are you pulling from the trunk or the branch

beppe, I'm using a commercial nightly build (also 2001062704) on Win2k and the arrow keys are definately not working, in any plaintext editing. I also see the cursor get stuck in the middle of lines sometime when moving sideways with the keyboard. Adding nsBranch keyword back until it's confirmed that this does *not* happen on the branch, shipping with this bug would be disasterous.

nsBranch is only added when it is approved for checking in, please do not readd that keyword

Beppe, please accept my appologies for re-adding that keyword, I'm lost in this forest of keywords. Btw, this also happens with todays nightly builds on Win2k.

cc akkana akkana--this sounds like the bug you noticed about control-w (delete previous word) not going to previous line.

Yes, I see this on Linux too, I agree that it's extremely annoying, and I suspect Kathy's right that it's related to delete-word not deleting past the beginning of lines (the two problems appeared at about the same time). I'd take a WAG that it might be related to recent edit rules changes.

I can confirm this on branch mozilla builds 062903 on win2K, linuxRH6.1 and Mac OS9.1 This affects right and left arrow in plaintext fields like the Bugzilla Additional Comments box. The arrow works if the line was wrapped but not if broken by a return/enter key.

assigning to mike, he has other navigation issues, and cc jfrancis

This should IMO be a mozilla0.9.2 stopper, and absolutely a rtm stopper.

yes I see this also using 6/29 builds...very easy to reproduce: 1) launch netscape 2) jump to Bugzilla page 3) enter a new bug report 4) in description field, enter two lines of text 5) go to beginning of second line of text 6) hit left arrrow it doesn't go to end of 1st line. also end of 1st line of text, hit right arrow, doesn't go to beginning of second line.

manager approval for checkin to trunk and branch, adding nsBranch keyword to denote that

here is a fix. backing out earlier test for BIDI check. this allows up to operate properly. the wrapping bug is also gone it appears probably from a different checkin on nsPresShell::CompleteMove. i will keep testing for that. but this at least stops the real real bad bug.

*** Bug 88549 has been marked as a duplicate of this bug. ***

Does typing lots of lines, pressing end to get to the last letter of the line, and not being able to hit the left key take part of this bug? I have got bug 88710 telling this Please mark as dup or new as adequate

*** Bug 88710 has been marked as a duplicate of this bug. ***

*** Bug 88871 has been marked as a duplicate of this bug. ***

*** Bug 88720 has been marked as a duplicate of this bug. ***

Bug 88909 reports similar problems about the Mailnews Composer. Is this the same control ? (If yes then this would be the 4th dupe today)

Adding access, nsbeta1, testcase. Summary changed from: "Plaintext editor keyboard navigation is hosed" Keyboard problems seen in testcase: 1. Left arrow doesn't move left to end of previous line 2. After pressing "End" key, cursor cannot be moved left 3. After typing letters at the end of the line, then clicking to move the cursor into the X's, the cursor cannot be moved into the new letters. 4. In a similar situation, after clicking into the new letters the cursor cannot be moved into the X's. 5. For the record, this isn't a problem but when pressing "End" at the end of a line the cursor will move one or two pixels to the right. This also happens when I press "down" at the end of the last line. 6. When pasting a two-line string like "a\r\nb" at the end of a line after doing that one-pixel trick, the "a" will be pasted at the start of the next line even though it should be pasted where the cursor is located. 7. Also, after doing that one-pixel trick, sometimes pressing the "Enter" key will insert TWO newlines instead of just one. Once the content of the textbox is long enough to require a scrollbar, keyboard navigation sometimes behaves itself, but not always. If it weren't for the mouse workaround, I'd add dataloss. Keyboard-only users are faced with an accessibility problem.

*** Bug 88909 has been marked as a duplicate of this bug. ***

*** Bug 88635 has been marked as a duplicate of this bug. ***

*** Bug 88842 has been marked as a duplicate of this bug. ***

*** Bug 89004 has been marked as a duplicate of this bug. ***

*** Bug 89050 has been marked as a duplicate of this bug. ***

we should go ahead and get this on the branch as soon as this is ready.

*** Bug 89122 has been marked as a duplicate of this bug. ***

*** Bug 89140 has been marked as a duplicate of this bug. ***

I would like to up this to a P1. This is a serious accessibility problem. Anyone disagree?

That's probably a good idea. None of mjudge's higher priority Editor bugs are more important than this. Bug 4302, bug 55031, bug 87662, bug 6270, bug 52868, bug 82993

*** Bug 89316 has been marked as a duplicate of this bug. ***

*** Bug 89370 has been marked as a duplicate of this bug. ***

*** Bug 88756 has been marked as a duplicate of this bug. ***

*** Bug 89334 has been marked as a duplicate of this bug. ***

backed out. all is gut

*** Bug 89338 has been marked as a duplicate of this bug. ***

*** Bug 89571 has been marked as a duplicate of this bug. ***

*** Bug 89594 has been marked as a duplicate of this bug. ***

*** Bug 89608 has been marked as a duplicate of this bug. ***

Verified 2001070604 Win98

*** Bug 89729 has been marked as a duplicate of this bug. ***

*** Bug 89821 has been marked as a duplicate of this bug. ***

verified on 7/9 trunk....will verify on branch and add comments here.

*** Bug 88047 has been marked as a duplicate of this bug. ***

verified on 7/9 branch and latest trunk. marking verified.

*** Bug 90121 has been marked as a duplicate of this bug. ***

*** Bug 90227 has been marked as a duplicate of this bug. ***

*** Bug 90265 has been marked as a duplicate of this bug. ***

*** Bug 90277 has been marked as a duplicate of this bug. ***

*** Bug 90291 has been marked as a duplicate of this bug. ***

*** Bug 90344 has been marked as a duplicate of this bug. ***

*** Bug 90141 has been marked as a duplicate of this bug. ***

(Build ID 2001071108 - Linux) Is it the expected behaviour that moving the caret right to the end of the text area wraps to the beginning of the area? Just hold down cursor right to reproduce this.

*** Bug 90517 has been marked as a duplicate of this bug. ***

*** Bug 90632 has been marked as a duplicate of this bug. ***

Michael Schwendt: moving the caret right to the end of the text area wraps to the beginning of the area is bug 82151.

*** Bug 90656 has been marked as a duplicate of this bug. ***

*** Bug 90848 has been marked as a duplicate of this bug. ***

*** Bug 90935 has been marked as a duplicate of this bug. ***

*** Bug 91262 has been marked as a duplicate of this bug. ***

*** Bug 91976 has been marked as a duplicate of this bug. ***

*** Bug 92038 has been marked as a duplicate of this bug. ***

Editor is much better on build 2001073003 but still at least 2 problems: Shift right does not always move cursor correctly. 1. Type a line of text with spaces 2. Hit "end" 3. Append a space and some text to the line. 4. Hit "home" 5. Hit shift right arrow repeatedly. Cursor will move to beginning of each word, which is correct. But on last word before more text was appended, cursor will move to original end of line, which is wrong. Editor still has other probs. While editing this text, changing "cursor will move to end of last word on original line" to "cursor will also move to original end of line" caused that text to vanish from the display. Text was still present, just not displayed. Had to add and delete some junk to get the display back. Tested build 2001073003 Windows version.

Mistake in editor bug report on build 2001073003: The key that moves to beginning of next word is ctrl right arrow not shift right arrow

Brent, let's not morph this bug about stuck carets into something different. Let's file a new bug on what you are now seeing. Remarking FIXED.

For those interested, I filed bug 92850 for the issues Brent mentioned above.

*** Bug 93250 has been marked as a duplicate of this bug. ***

I can see one little annoying bug remaining here. 1) Go to the bottom of the text 2) Place the cursor at the end of that line 3) Press the down arrow. (It should stay at the last line, this is ok) 4) Press enter. The cursor goes down 2 positions down instead of 1 as you would expect.

I have also noticed some frustrating behaviour when navigating around quoted text. I'll report details when this happens again. This bug is definetely stil not fixed.

If you type enough text into a field to warrant a scrollbar, hitting the right arrow key takes you all the way to the beginning of your typed in text. The 'normal' behavior would be to have the cursor stop and not wrap to the beginning of the entered text. If, however, people like this action as an enhancement, then I would pose that hitting the left arrow key at the beginning of the text should take you to the end of the text (reversing the right arrow). I use the right arrow key a lot in determining if I am at the absolute end of a line of text. When entering lengthy text into a text box under Mozilla, I am constantly annoyed when I get sent way back to the beginning with no way to undo that action. I'm not sure if this is because of this bug. If not, perhaps a new bug report should be filed...

Kevin: that's a bug (or, at least, I hope so). I think someone filed it recently, but I'm not sure and don't have the number offhand. You might check mjudge's and anthonyd's lists. Or file a new one.

verified in 9/4 build.