From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801 BuildID: 2001080110 On Windows systems the user can use several keyboard shortcuts in virtually every edit field. In Mozilla, if the end of a one-line edit box is reached (by pressing Ctrl-right several times), the cursor jumps back to the beginning of the text when Ctrl-right is pressed once more. Reproducible: Always Steps to Reproduce: 1. goto any one-line edit box 2. type in several words separated by spaces 3. position the cursor at the beginning of the text 4. press Ctrl-right until the cursor is located behind the last word 5. press Ctrl-right once more Actual Results: The cursor will jump back to the beginning of the text line. Expected Results: The cursor must remain at the end of the line (as it does in multi-line edit boxes and in other apps one-line edit boxes).

Reassigning.

-->editor (dup?)

I don't see this happening on the trunk build from 8/8, win98 -- reporter: do you still see this?

Yes, I can still can reproduce it fully (now I even checked it with WinME; before was Win2000) with build 2001080804. This is how you can see the effect: 1. Go to the Mozilla homepage 2. Click on "Report A Bug" 3. In the yellow "Search Bugzilla" field, type several words. 4. Pressing Ctrl-Right will have no effect in this particular field, but pressing Ctrl-LEFT will jumb back to the end of line after the head of line was reached 5. Go to any other input filed on this side (e.g. "Build ID" or even the multiline edit box "Description") and type some words 6. In all these other input fields, the effect of the line-jumping input cursor will appear by pressing Ctrl-RIGHT (whereas Ctrl-Left has no malfunction in these fileds)... Very strange. Ciao, Alex

That is bizarre, I now see the problem, and I am now able to get it to happen in other documents. But not in a bug query, like the Summary text widget on this page. The ctrl-left or ctrl-right should stop at the beginning or end, respectively. Attaching a reduced test case

wow, I found something really weird, if the input field wraps to the next line, it wroks right, if it doesn't wrap it won't work right -- look at the attachment

--> mjudge (caret navigation)

this is from a white space issue. kin has these on him plate. marking this as wont fix

okay marking verified...Kin has this on his plate...right Kin ?

I don't have any caret wrapping bugs related to whitespace on my plate. The whitepace issues I have on my plate regard the fact that layout frames don't reflect trailing whitespace. Following the directions in this bug I can reproduce the problem without using any trailing whitespace. If it is indeed related to something on my plate, don't close this as won't fix, mark it dependent on the bug I have. And give us more info on what's happening here. Why is it a whitespace issue? I noticed you need a single space between words to see this problem, but why does the caret navigation code sometimes allow wrapping with ctrl-left and ctrl-right at sometimes and not others even when spaces are involved?

text area nav, marking EDITORBASE.

plussing

all of these things use the same code, so there's no need for more than one bug about this one problem. *** This bug has been marked as a duplicate of 82151 ***

verified.