Build: 2001052115, Mac OS 9.1 To reproduce: 1. In the `Additional Comments' field in this bug report, enter three or four lines of text. (`Lorem ipsum dolor sit amet', copied and pasted several times, is always a good standby.) 2. Place the caret somewhere in the middle of the text. 3. Hold down the Down arrow key, and watch as the caret comes to rest at the end of the text. 4. Press the Right arrow key, and watch as nothing happens. 5. Now, enter a few more lines of text, such that the textarea has a vertical scrollbar. 6. Repeat steps (2) and (3). 7. Press the Right arrow key. What should happen: * Nothing. What actually happens: * The caret moves to the beginning of the first line of the textarea.

*** This bug has been marked as a duplicate of 80937 ***

verifying duplicate

Bug 80937 has been fixed, but this bug hasn't been -- reproduced on build 2001052904, Mac OS 9.1. Reopening.

Verifying on NT 4 sp6, mozilla build 2001052904. Now there is a scrollbar, pushing right arrow next and the caret goes to the beginning.

-->mjudge since he was in this code recently for some other bugs

sr=kin r=cmanske simple fix i think good for 9.1 but we can wait for 9.2.

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

Is this going to get checked in anytime soon ?

I've seen this bug for the last YEAR or two on Linux builds. However, until recently, it would wrap back to the start of the last line, not the start of the entire text area. Now that it jumps all the way back to the start, it's quite a bit more blatent, which is why it seems to have been noticed -- did it really go unreported for a year or more? Why didn't I report it, you ask? (1) It seemed so obvious and basic that someone must have reported it already. (2) It's not always easy to find existing bugs in Bugzilla. (The Debian bug-tracking system always seemed easier to use, somehow.) (3) I didn't want to file a duplicate bug report on something so obvious. (There have been cases in the past where I've searched for a bug yet couldn't find it until my report got resolved as a duplicate -- I'd rather not create such clutter in the system.)

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

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

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

its all in

This is fixed on build 2001-06-15-08-trunk on Mac OS8.x but I still see this behavior on build 2001-06-15-08-trunk Linux RedHat 6.2

i am at a loss as to why this would be different on one platform or another. I will have to find someone with a linux build now.

changing whiteboard

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

ok there WAS 1 last thing. It is the SCROLLBAR that is on by default that was causing this to show up on linux only. once we have a scrollbar on windows the same thing happens. IBMBIDI was behaving oddly and doing some code i was not familiar with. I added a check to NOT execute that redundant code if the frame in question was not BIDI. similar check to other places in the app. fixes the wrapping on ALL platforms.

last 2 comments and the patch were done by mjudge@netscape.com on kins machine. direct all comments to mjudge ;-)

sr=kin@netscape.com ... FYI the patch mjudge just posted is done with cvs -uw the changes you don't see are just indenting existing bidi code so that it lines up properly under the 'if' check that mjudge added.

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

checked in

If you put in several lines of text into a text field and a scroll bar appears, the problem still occurs on all platforms. Reopening.

Vladimire is right, I just verified that the 06/19/01 15:04 patch was never checked into nsFrame.cpp.

checked into branch and trunk anthonyd

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

The bug is not completely fixed. The cursor doesnt go to the beginning any more, but if you go to the end of a text box and press down arrow the cursor will jump to the end of line and when you press left arrow it doesnt move left. Expected Results: when you are on the last line and pressing down arrow nothing should happen like you didnt press the arrow at all. Meaning it should stay in the same spot, and should be movable.

manager reviewed the need for the fix and agrees, approval for checkin to the trunk and branch after fix has received an r= and sr=, adding nsBranch keyword

If the caret is in the middle of the last line of text, it should move to the end of the text (and be movable) on Macintosh if the down arrow key is pressed. Similarly, if in the first line of text, pressing the up arrow should move the caret before all of the characters. If there is a problem with this behavior, it should probably be filed as a separate bug. "The cursor doesnt go to the beginning any more" sounds like bug #88164 which was fixed yesterday. I think this bug is fixed so I'm resolving as such; please reopen if you see the problems described (not #88164).

The cursor goes to the beginning on 2001-07-09-05-0.9.2 windows 98 and 2001-07-09-04-0.9.2 Linux RedHat...

interesting discovery, it seems to only happen the first time that you arrow to the end with the down arrow key. If you hit end (after the caret ends back at the beginning of the line as mentioned in the steps) and then hit right arrow again, nothing happens. tested this on win98 using trunk build from 7/9/01, removed data from whiteboard

Bug happens on win98, Mozilla build 2001071214 (trunk). Can reproduce exactly as originally described, except that at step 4, the cursor may sometimes move to after the first character of the last line. Also, down arrow is not needed; just type randomly until scrollbar appears, any moving right or ctrl+right past the end jumps to beginning of text.

still happening in build id: 20010724-18-0.9.2 in win2000.

over to 9.4

Occurs in Win2k (at the least) regardless of whether or not there's a scrollbar when the textarea is defined as "wrap=virtual" (such as on the slashdot site). (Build ID 2001080110).

I noticed that this occurs with both right arrow key , as well as, ctrl + right arrow key. The cursor keeps looping in the textarea field.

This is not just TEXTAREA! Bug 94119 reports the same problem with inputs that have size attribute set.

-> 0.9.5. sorry, we can't deal w/ regressions like this right now.

If this is important to someone for 0.9.5, tell me now so I can find another owner for it. mjudge won't be back until 0.9.6.

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

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

-> 0.9.6

Shift Right Arrow at end of a TEXTAREA selects all the text in the TEXTAREA.

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

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

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

User Agent String: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011 Please note that this is a build from a few nights ago. I'm still experienceing this bug, and it's really become quite bothersome, as I've begun submitting more stuff here that requires use of the TEXTAREA, resulting in this bug bothering me more the more bugs I report. FIX IT ALREADY! Sorry, that was uncalled for.

Lorem ipsum dolor sit amet steps are works for me on Linux, at least, to my naive eyes the cursor movement with arrow keys as reported originally works fine. Can someone post some steps that illustrate this problem (or close the bug if it really doesn't exist?)

I see the problem with the original steps to reproduce: 1) put one char on each line of the textarea, hitting enter after each one till the scrollbar appears. 2) hold down the right arrow key and watch the cursor loop. This is with a 2001-11-02-08 build.

adding back dependencies that went away for some reason...

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

noticed that the looping with 1. right arrow 2. ctrl + right arrow only happens if the vertical or horizontal scroll bars appear in the textarea.

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

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

0.9.6 is gone -> 0.9.7

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

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

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

This bug has 16 duplicates. Doesn't it deserve "mostfreq" status yet?

and 19 votes... pushing it into the "nagging users" category :)

There's no "mostfreq" keyword anymore, see http://bugzilla.mozilla.org/describekeywords.cgi. Most frequently reported bugs page is updated automatically. This bug is already listed there, thus no need for complaints here.

Nominating for nsCatFood based on keywords thingie :-)

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

There are other caret-at-end-of-textarea misbehaviours too. This is in Mac build 2002010408. 1. Type a few lines into a textarea. 2. Place cursor in the middle of last line. 3. Press down arrow key to move caret to end of last line. 4. Press right arrow key. Expected result: Nothing. Actual result: Caret moves to 2nd positon of last line. Also try: 4. Press left arrow key. Expected behaviour: Caret moves 1 step left. Actual: Caret moves to end of above line. So it's obvious that Mozilla displays the caret at end of text, but treats it as at beginning of last line. Here's another one: 1. Type a few lines in a textarea. 2. Place a newline at end of last line, creating an empty line. 3. Place cursor in the line above and press arrow down key. 4. Press arrow down key again. 5. Press arrow down and hold. Expected behaviour: Nothing. Actual: At (4), caret jumps to end of line above. At (5), it cycles between those two positions.

Wait, Travholt. your bugs of comment #67 are different from original reported bug, I think. Because original bug occur only after scrollbar appeared. bugs of comment #67 always occur. see Bug 113260 and Bug 106855.

Argh, this bug has plagued me for years. With every version of Mozilla, as it was downloading, I'd say to myself "Surely, THIS version must fixt the textarea cursor issues." I don't have anything else to add, I'm just complaining.

This doesn't seem to require a scrollbar--I can do it with a single line of text. And it doesn't always seem to be the beginning of the line; try this: 1. Enter some characters ("abc" will do) in the bottom line of a textarea. 2. Press down arrow. 3. Enter some more characters ("xyz"). 4. Press down arrow. 5. Press right arrow. The caret moves to after the "x". (Pressing Left instead moves the caret before the "c".)

Noble target, but you might want to bump it up two notches. Does this bug also cover the issue of 'down arrow, LEFT arrow' moving to the end of the line above the last? I should also mention I see the cursor move 1 pixel left often when I hit down arrow on the last line. Seems to occur more often after typing an 'e'. Pressing the 'end' key moves it 1 pixel back to the right. I can continually press down/end/down... and watch the cursor jump back and forth 1px.

Adding more reasonable nomination.

Note that there is a patch in the bug 106855 which maybe could fix this bug.

See also bug 103039 "Line editing in text entry boxes messed up".

To reproduce: 1. In the `Additional Comments' field in this bug report, enter three or four lines of text. (`Lorem ipsum dolor sit amet', copied and pasted several times, is always a good standby.) 2. Place the caret somewhere in the middle of the text. 3. Hold down the Down arrow key, and watch as the caret comes to rest at the end of the text. 4. Press the Right arrow key, and watch as nothing happens.

Hoppla... Sorry for the spam... :(

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

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

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

Mike, curious, I dont see mention of driver approval yet for this on the branch.. let alone bug 106855. Someone added it to the dependency for 0.9.8.

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

To make it clear what's the real issue. The various behaviours described in comments 70, 75 and maybe others are fixed by the patch to bug 106855. But the originally reported behaviour (the same as comments 52, 55) is not fixed by the patch.

nsbeta1+ per ADT triage team

editorbase+ per meeting

Comment #82: Tom, the issue in comment #70 is not fixed by the patch either. It's still reproducible in Mac build 2002021208. However, it's just in the first line. It's a minor bug, but it's still a bug. :-) Upon checking out this, though, I found ways to reproduce another one, which I haven't seen reported anywhere, so I'll report it now. (These last two paragraphs are written to check the effects of that bug.)

I found very instructive test cases. Please check two test cases below. I confirmed on 0.9.8/Linux and 2002021621/Linux.

This test case is no problem. and Right-arrow cause nothing special.

This test case is almost same with one above. But there is some magic. :-) This test case gives you some insight, probably.

Sorry, two test cases have a mistake like: COLS=40"> It should be COLS=40> . Even if you fix them, these test cases are significant.

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

I filed comment 70 as Bug 127554. and I wrote a patch to fix the bug.

I tried to write a patch. And this is the result. This patch fixes Bug 93192 also. It prevents nsLeafIterator::Next() and Prev() from ascending parent Frames above "scrollFrame". I don't know much about whether this is a good way or not. Comments welcome.

still see this happening on win2000 03-07-10trunk build refer to my comment #55

removing myself from the cc list

got same bug on nt4.0 sp5, mozilla 0.9.9 build 2002031104 would even be okay if you could get back to the end with the left-arrow-key,but that's blocked!

still see it happening with yesterday's nightly on mac os 9.2

CCing jfrancis as he works on other textarea bugs too. Please look at the patch if you can...

In the second patch, if you are going to check for a null frame state, you should initialize it to zero. There is no nsFrameState constructor to do this for you. The selection changes look ok. I'm really not well qualified to evaluate the rest.

restoring dependency. Please do not remove dependencies without good reason (they denote a lot more than "this bug needs to be fixed to fix that bug")

if we hit a scrollable view. sometimes we need to stop. (i.e. edit box/ text area) If we have a limiter on selection then play it safe a stop iterating when we hit a scroll view. more complicated than the last patch but allows us to jump out of scrollable frames in the case of say a scrollable table cell or something like that.

Comment on attachment 77364 [details] [diff] [review] regulates when we stop when we hit a scrollable view in the frame tree -- Need to remove one of these duplicated statements in nsLeafIterator::Next(): parent = result; + parent = result; -- Do you really want to check in the #ifdef/#endif DEBUG_skamio printfs? If so, lose the spaces before the #, I seem to remember some compilers choking on that in the past, but things may be different now. -- You do this casting of (PRBool)mLimiter in 2 places in nsSelection.cpp: + pos.SetData(mTracker, desiredX, aAmount, eDirPrevious, offsetused, PR_FALSE,PR_TRUE, PR_TRUE, (PRBool)mLimiter); please change them so that a real PR_TRUE or PR_FALSE value is used, for example use: mLimiter != nsnull -- Why do the SetData() calls in nsFrame::PeekBackwardAndForward() hardwire the aScrollViewStop arg to PR_TRUE? Shouldn't they ask the selection if it has an mLimiter and base what it uses on that? -- Please add spaces between the "," and what you added in these portions: - aPresContext, resultFrame); + aPresContext, resultFrame,aPos->mScrollViewStop); - : traversedFrame); + : traversedFrame,aPos->mScrollViewStop); - result = NS_NewFrameTraversal(getter_AddRefs(frameTraversal),LEAF, aPresContext, traversedFrame); + result = NS_NewFrameTraversal(getter_AddRefs(frameTraversal),LEAF, aPresContext, traversedFrame,pos->mScrollViewStop);

removed extra line. removed extra spaces. removed #'d for debug statements. changed prbool casting peek backward and forward is used for jumping words or paragraphs. the paragraph in my mind is good to stop on a scrolled view. (i.e. tripple click and dont select out of a scrolled view). Also there is no current way to go from nsISelectionController to get the limiter. nsISelectionController has no such concept. I think some QI work could go into getting the nsIFrameSelection to then get the limiter and if one exists to then pass in the parameter properly, but I dont see the reward for the extra complication since its not really necessary in that case.

see above comments

Comment on attachment 77946 [details] [diff] [review] fixed small things from kin's comments sr=kin@netscape.com This isn't the entire diff of all your changes, but answered my one question above, and this change was the only one I was concerned about.

this is since jfrancis is unavailable for r= on new bug i am posting full new diff for someone else to review.

Confirming patch 78272 works on linux. Any chance of getting the patch onto the branch? Looks like just a= is needed from the attachment status above, but the comment below looks like r= is still needed as well??

Comment on attachment 78272 [details] [diff] [review] full patch including change for kin. a=asa (on behalf of drivers) for checkin to the 1.0 branch

adding adt1.0.0 nomination

Pls check this into the trunk for a couple of days, and have QA verify that the patch resolves the issue, and does not cause any regression.

Red Hat Bugzilla equivalent to this bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62311 Red Hat mozilla-0.9.9.7.src.rpm merged with this patch. http://videl.ics.hawaii.edu/~warren/ I manually merged "full patch including change for kin." with Red Hat's mozilla-0.9.9-7.src.rpm and have been tested it for a day. I have found that it fixes most of this bug but with one exception. If you scroll all the way down with the down key so that the cursor jumps beyond the final character, the right key makes the cursor jump to the beginning of that line. I suspect that this other behavior is due to another bug fixed since 0.9.9. Is this the case? What version of Mozilla should I merge the full patch above with in order to do proper testing?

i have this patch applied to latest trunk and I cannot reproduce the problem you are seeing. Either A) I am not doing the right thing in which case I would like exact steps to reproduce or B) This was fixed by some other but patch. I am hoping for B but I would like you to really spell out what you did to cause the caret to move to beginning of line. Were you in composer or a text area, what to type in ect. Thanks a lot.

I just tested nightly 2002041510. It worked properly in that build, so the "right key going to beginning of line" must have been another patch. Any idea which patch this was? I hope these fixes can make the next Red Hat release.

mjudge: you caused bustage on Ports. please fix it. 1018926840, Linux myotonic Clobber Build Error Summary C -I/usr/X gmake[6]: *** [nsFrame.o] Error 1 /builds/tinderbox/SeaMonkey/Linux_2.2.19-6.2.12enterprise_Clobber/mozilla/layout/html/base/src/nsFrame.cpp: In method `nsresult nsFrame::GetFrameFromDirection(nsIPresContext *, nsPeekOffsetStruct *)': /builds/tinderbox/SeaMonkey/Linux_2.2.19-6.2.12enterprise_Clobber/mozilla/layout/html/base/src/nsFrame.cpp:3845: `pos' undeclared (first use this function) /builds/tinderbox/SeaMonkey/Linux_2.2.19-6.2.12enterprise_Clobber/mozilla/layout/html/base/src/nsFrame.cpp:3845: (Each undeclared identifier is reported only once /builds/tinderbox/SeaMonkey/Linux_2.2.19-6.2.12enterprise_Clobber/mozilla/layout/html/base/src/nsFrame.cpp:3845: for each function it appears in.) /builds/tinderbox/SeaMonkey/Linux_2.2.19-6.2.12enterprise_Clobber/mozilla/layout/html/base/src/nsFrame.cpp:3850: warning: unused variable `struct nsRect testRect' gmake[6]: *** [nsFrame.o] Error 1

i changed pos to aPos. I'm watching myotonic. Matti also hit this (gmake, windows, disable bidi)

in trunk. hmm i will look at patch to see how i messed that up for ports. sorry about that. Thanks for fixing it! Warren could you test the 1.0 branch? see if the beginning of line is fixed there before I land this patch on it? P.S. sujay please test this;)

I feel compelled to point out that --disable-bidi is NOT a very healthy configure option to be using. See bug 89203 (and 88509 and 86517 which inspired it) for the discussion to remove it alltogether.

Changing qa contact, Mike I'll test on branch and get back to ya

Terri - You mean to test this on the trunk, right? This is not on the branch yet.

This is fixed using win XP trunk build 2002041603 Mac OS X trunk build 2002041603 and linux trunk build 2002041609

adt1.0.0+ plesase checkin to branch asap and add keyword fixed1.0.0

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

adding fixed1.0.0 and marking fixed

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

Verified fixed Win 2k branch build 2002042203, Mac OS X trunk build 2002042205 and linux trunk build 2002042208

Verified fixed Win 2k branch build 2002042203, Mac OS X trunk build 2002042205 and linux trunk build 2002042208

Common case fixed, uncommon case still buggy: Open a Yahoo or Hotmail Mail account. Recieve some mail. Select "reply" so that the mail gets quoted in the main textarea. Now hold down "Ctrl" and move the arrow forward so that the caret skips one word at a time (as it should). At the end of the textarea, the caret will still wrap.

I reproduced what Soren Ragsdale described, but with one exception. Wrapping only occurs when there is a scrollbar present. (Mozilla 1.0 Release Candidate 1, Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020416) Should this be a new bug since it includes the control key? While I tested this I found another oddity control and left arrow does no reach the first empty rows. To reproduce: Press enter a few times in the additional comments field in bugzilla. Then enter some text. Use control-left arrow to go back to beginning. Expected result: Caret should reach beginning of the first line. What happens: Caret stops at the beginning of the first line to have text in it. I filed this as a new bug (139402) since it isn't in the depends list of bug 108120.

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

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

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