User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030225 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030225 When editing mail messages, sometimes the cursor can go up when you press down arrow. I just downloaded the nightly build, so this should be new software. Reproducible: Always Steps to Reproduce: 1. Make a new mail folder 2. Grab the attachment that I will attach here and overwrite the mail folder with it. It will be a .gz compressed text file. 3. Reply to the message in the mail folder 4. Click the mouse on the first blank line of the message 5. Press down arrow until you reach the line that starts with "The ejb" 6. Press down arrow Actual Results: The cursor went up Expected Results: I would expect the down arrow to make the cursor to go down

This is probably a selection bug and may well be a duplicate of the caret regression. David Campbell--are you using html mail or plaintext mail when you reply? Can you try a newer build (2/26 or newer)? It'd probably be easier to get a fix if you could try this: copy the message you see after step 3 (select all, copy) open a new composer window (control-4) paste into the composer window save as html file close window open a new composer window and reopen your file from Recent menu (under File) If you see the problem there then attach the file here since that will be easier for everyone to see the problem and reduce to a more minimal testcase. If you don't see the problem, report that here...

I can't use a newer build as far as I know because I only downloaded this version a few hours ago. It's the one from "nightly builds". The message that is being replied to does contain html so I presume that the reply is html.

This is probably a duplicate bug but maybe not... Thanks for the testcase; I see the problem in Netscape 7.x on Macintosh OSX also.

I still see this problem in my 4/3 debug build on macho

-> me

This is derived from the previous attachments. It is the smallest HTML that demonstrates the problem. (You never arrive at "b" using only cursor down)

This HTML has only one small difference, but this difference makes the editor work correctly. The difference is only in whitespace between <br> and </i>. I tested various types of whitespace, carriage returns, spaces. As soon as there is at least one space or carriage return, the bug shows up. Does this indicate a bug in nsWSRunObject? I'm investigating further.

> Does this indicate a bug in nsWSRunObject? Arrowing around with the caret usually has nothing to do with editor code.

simple explanation: this may fix the issue. the problem is that nsLineBox returns 0 width frames as valid frames to find on a given line. by skipping 0 width frames we allow nsLineBox to find the valid BRFrame. more complicated: before since the caret was at XOffset 0 the empty InLine frame on that blank line was returned from nsLineBox. Then GetContentOffsetsFromPoint did not fail. Instead it thought since it had 1 child (a 0 width text frame) and since that text frame was not satisfactory (0 width) it instead returned its own content with as good an offset as it could find (which was the SPAN element at offset 0) 0 since the xoffset of 0 was before the empty lines bogus inline frame. This then leads to the caret jumping back to the top of the span. Rather than play the game of getting getcontentoffsetsfrompoint from special casing the heck out of itself for inflow elements etc, i skip the whole problem by not allowing the linebox code from returing 0 width frames no matter how "close" it thinks they are. if it has no frames it just returns an error anyway.

well i tried to get cute and make last minute change without testing. doh. thanks kaie for the catch. nsLineBox will always return at least 1 frame if its the only frame and even if it has 0 width.

With this patch I can no longer reproduce the bug.

Assigning back to mjudge, because he produced the fix.

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

Comment on attachment 120248 [details] [diff] [review] patch 1.1 for nsLineBox.dif The safety checks look reasonable to me. r=kaie I've also tested that this patch fixes the problem in 202407

Comment on attachment 120248 [details] [diff] [review] patch 1.1 for nsLineBox.dif Would prefer to see if (foo.width > 0) in all the tests, but looks sensible.

checked in

looking at the minimal test case (attachment 120194 [details]), the issue with the down arrow key making the caret move upwards is no longer a problem when using a build from 2003.04.22.03. however, this regressed with a build from 2003.04.23.03, so reopening. perhaps the fix to bug 202834 caused this to regress.

this fixes regression. we must test nextframe against stoppingframe after it has the chance to be assigned into the currentframe. I made sure that all bugs with clicking on lines are also still ok.

I believe this is fixed and just not marked. I will check code and verify

I can confirm the latest patch has already been checked in to the trunk. Marking fixed.

tested using trunk build from today [2003051308] on winXP, and the reduced test case now works fine (comment #8) test case from comment #4 also tests fine marking verified