Found on 6.1b beta release build using Win98-en. I've run into the following scenario on many occasions, but since the problem does not consistently occur, I have not yet been able to come up with a definite set of steps to reproduce it. As soon as I do, I will post them here. Sometimes when selecting and then deleting (using Del key) a line of text (usually a bulleted line, but I can't remember if it just happens for bulleted lines), the text on the selected line as well as on the previous 1 or 2 lines gets cleared as well. The cursor ends up on the top-left corner of the window, and any attempt to undo the change fails. Also, I've often noticed after this happens that scrolling the window causes text near the top of the window to disappear from view. If I save a draft of the message, I can see the text that disappeared from view when I reopen the draft, but the lines that were deleted are gone for good.
Jfrancis knows more than the rest of us about this black voodoo. ;) CC him
reassigning to jfrancis since this doesn't sound like it would only happen in mail.
I would suspect that the next time you see this happen, the caret had been associated with a larger chunk of data than you had anticipated. There are several bugs assigned to jfrancis that refer to the 'ubercaret' -- this is probably a dup of those
Do you have a build date for this problem? There was a fix for a problem similar to this that went in a couple of weeks ago.
As I stated above, I hit this problem in the 6.1 beta release build, which was 06-07-13-0.9.1. I will see if I can reproduce the problem in a later build, but as I have said, this bug can be difficult to reproduce.
don't forget to look for the ubercaret too -- also, when it does happen you can do multiple undos and redos to figure out how to reproduce it
need help in narrowing this one down
I'm currently using 07-03-06-branch. The most notable problems I've been seeing with this build are the following: 1) Text in top third of compose window sometimes disappears when deleting text on a line lower in the page. 2) Deleting characters results in "phantom" characters (such as a semi-colon) appearing on the previous line (right before the line break). These problems are not permanent; if the message is saved or sent, the hidden text reappears, and the phantom characters go away.
sending to kin for disposition. sounds like a layout issue; the content is being properly editted, but layout is getting confused when reflowing.
seems related to bug 104936.
Are you using Plaintext Mail Compose or HTML Mail Compose? It sounds like HTML Mail Compose since your first description of the bug mentioned List Items ... right? In any case please be specific. It looks like there are 3 bugs reported here: 1. Delete causes previous lines to disappear. (List items mentioned) 2. Redraw problems when deleting at bottom of page. (Bug 97674, fixed already) 3. Deleting causes phantom characters. Item 1 sounds a lot like bug 101690, but that bug only happened in Plaintext Mail Compose. Are you still seeing it in more recent builds? FYI, Bill Ruppel's bug 104936, turned out to be a dup of 101690. Item 2 should be fixed on the TRUNK as of last week. Item 3 should have it's own bug filed with steps on how to reproduce it.
I'm still seeing similar problems with the 10/22 M0.9.4 build.
Repro steps: (1) Send an "test" email of more than 21 full lines. (2) From the sent folder, open the "test" email, click reply all. (3) copy the whole text of the email, paste to the top of the email. (4) edit the top portion that has been copied over, such as add a new hyperlink to a bug, add some new lines. (5) delete the bottom portion. Expected result: Only the top edited portion will be displayed. Actual result: Almost all of the text are gone. Only one top line shows up in the compose window. Walkaround: Resizing the compose window will bring back the expected display. I have a sample email if you need some help to repro this. Please email me (email@example.com) if you need it.
Jon Rubin - Do you have any additional info you can provide to help me out here? See my questions/comments above in comment #11. Do you still see the problem with TRUNK builds? I think the bug Tiantian is describing is bug 97674 which is fixed on the TRUNK but not on the 0.9.4 branch. It sounds very different from what the original reporter of this bug describes.
Moving out to mozilla1.0.1 until I get additional info.
Is this bug still open? I can't reproduce it anymore using 2002040103 on WinXP. Message editing (both HTML and plaintext) is very stable and predictable for me these days.
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070109 SeaMonkey/1.5a