These steps to reproduce comes from comment70 of Bug 82151. 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".)

I wrote a patch to prevent the caret beyond the last text-node.

changing os and platform to all. i'm seeing this with build 2002021708 under mac os x.

abcxyz

This patch is better than one before.

I added some comments to my patch. Please review it, kin or jfrancis ?

It's worth noting that the behavior after the first down arrow is also wrong. xyz should not appear on a new line, but instead right after abc. Down arror must be setting the selection after a trailing br in the text area. That makes sense from a selection standpont, but the editor must not allow typing to occur there (after an invisible br node).

I've been tangling with text area as part of bug 132133, and I think I might as well fix this too.

hmm... my patch to bug 132133 hides this bug. That is because that patch makes sure there is always a trailing break node in plaintext editors, so the situation here never arises. Ignore my comment #6. The fact that xyz draws on a seperate line was a problem on my build only from a bug in one of my patches.

There are some things I dont understand about the original code that Kamio's patch applies to. So I cannot review it unless I get mjudge or perhaps kin to explain some things to me. But if I land the patch to bug 132133 then this issue will be hidden.

fixed branch and trunk by bug 132133 landing

seems to w4m with recent comm trunk builds.