User Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 Build ID: 20140917194002 Steps to reproduce: I'm creating a pretty long document in Composer, which often demands me to rewrite or otherwise edit the already created text, adding/removing/modifying parts of it. For those tasks the Undo/Redo instruments are quite often used. Actual results: Sometimes - and i don't know the exact conditions, so i can't provide a perfect sequence of steps to reproduce - when you entered some text, then decided to Undo it, but after that realized that you wanna put it back so you wanna use Redo, Redo removes even more text instead of putting back what you had before. Once the faulty behavior expresses itself, the more you press Ctrl+Y, the more data is removed. Sometimes a whole paragraph is removed, which you definitely didn't edit during the current launch session of Composer so it cannot have it in its Undo/Redo action buffers. The hunch tells me that it might be related to the current cursor position. I.e. if you enter some text, move the cursor somewhere, then decide to undo the entered text, then maybe move the cursor somewhere else, then try to redo the text back - the chances of having a problem increase. Despite being hard to predict, such occurrences are not unique, i personally have faced them multiple times, so often that i try not to use the Redo function altogether. It's another reason why i can't provide a perfect reproduction sequence. Please don't close this bug as "NONREPRO", it's really there, i experienced it on both 2.24 and 2.26.1 (didn't use 2.29 version much since it's search functionality is broken). Expected results: What i expect is Redo function working stable and predictable, redoing what it must redo and not doing weird stuff it's not supposed to.

The initial bug description was quite incorrect, partly due to its difficulty to reproduce. This time i managed to provide a test case that works all the time. Open the attached file in Composer, and select the word "one" at the end of the second line, so that the selection also includes the dot and the invisible newline character. If you do that correctly and then press Delete, the second paragraph will get merged to the first one. Then, try to Undo the deletion. You will see that instead of the text "A new paragraph" appearing as a new paragraph, the result will be the following: the first paragraph ends at the first line of the text, and the rest is merged into a second paragraph starting with a blank line. Which obviously isn't what the text used to be before the deletion.

Well, UNDO <-> REDO definitively still is broken or at least crazy in MY German SeaMonkey 2.32.1 Build 20150204202218 on German WIN7 64bit is working. Generally that seems to start after I test undo/redo in composer, after that the function becomes crazy. I will have to do some more research to find out how that works. Any Hint how I can watch the undo-stack?

I did a quick test here in Comment field before I typed my comment: 1. login 2. Type a text: this is line 1 this is line 2 this is line 3. <contro+z> Expected: Last word "line" removed Actual: Complete text removed. There are lots of different crazy effects, but because I am not sure whether these problems are related to Add-ons or whatever I would like to wait for someone else confirming my observations. For me the effect is not limited to Composer. I did the same test with FF 35.0.1: also effected. I wonder whether this one might be related to "Bug 1015433 - Undo/redo corrupts editing text (contenteditable or designmode) "

My comment 3 is more appropriate to confirm "Bug 282638 - Undo coalesces too many edit actions" (I did so). but I did not see any remaining damages in my test texts, so back to UNCONFIRMED for now.

(In reply to Rainer Bielefeld from comment #4) > My comment 3 is more appropriate to confirm "Bug 282638 - Undo coalesces too > many edit actions" (I did so). but I did not see any remaining damages in my > test texts, so back to UNCONFIRMED for now. What about the test case i provided in the https://bugzilla.mozilla.org/show_bug.cgi?id=1070707#c1? Could you not reproduce the described behavior as well?

@Dmitry Semionin: The visible effect of your problem is tat REDO <control+y> does not restore the situation before UNDO?

(In reply to Dmitry Semionin from comment #1) > and select the word "one" at the end of the second line, so that the selection > also includes the dot and the invisible newline character. How ever that should be done. Reporter, please contribute a step by step instruction containing every mouse click and every key press. Currently NOT reproducible with reporter's sample and German SeaMonkey 2.32.1 Build 20150204202218 on German WIN7 64bit

Not reproducible and no response, so I close this one for now. @Reporter: Please feel free to open a new Bug if you still can reproduce the problem with a current SeaMonkey version, a blank new user profile and a current OS and if you can contribute a step by step instruction due to <https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines> (containing every key press and every mouse click) how to reproduce the problem reliably. Your description is much to imprecise, for example you say "select": left to right, right to left, mouse, arrowkeys, doubleclick? I recommend to open a new bug because this one already contains too many dead ends, it started as a "Redo" problem, became an "undo" problem ...