Using Build ID: 2002052508 Steps to reproduce problem: 1. Open Editor 2. Insert/Image 3. In the image location field, type #,BKSP,#,BKSP,#,BKSP,#,BKSP,#,BKSP 4. Press ^Z ten times, then ^Y ten times, then ^Z ten times Expected results: "OK" button is enabled when the location is # Actual results: "OK" button is enabled after typing each # as expected "OK" button is not enabled after any of the ^Zs "OK" button is not enabled after the first two ^Ys "OK" button is enabled on the 3rd, 5th, 7th and 9th ^Ys as expected "OK" button is enabled on the next ^Z as expected "OK" button is not enabled on any of the rest of the ^Zs

This now (since bug 60917 was fixed) also affects message compose. Steps to reproduce problem: 1. Open Message Compose 2. Focus the Subject field (Alt+S) 3. Type ^Z,^Z,^Y,^Y (at this point undo/redo should not be possible!) 4. Type #,^Z,^Z 5. Type #,BKSP,^Z,^Z,^Y,^Y Some very strange things happen to the title...

The second field in this test case is updated using onInput on the first field. The third field is updated using setTimeout to demonstrate a workaround. 1. Type #,BKSP,#,BKSP,#,BKSP,#,BKSP,#,BKSP 2. Type ^Z 10 times 3. Type ^Y 10 times 4. Type ^Z 10 times

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

Why hasn't this been fixed yet?

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

WFM instructions in comment 2 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007081503 SeaMonkey/2.0a1pre

(In reply to comment #6) >WFM instructions in comment 2 - Mozilla/5.0 (Windows; U; Windows NT 5.1; >en-US; rv:1.9a8pre) Gecko/2007081503 SeaMonkey/2.0a1pre Odd, because comment 2 is still broken for me, although comment 1 is WFM now.

is the problem of comment 2 the end state after step 4, or is it the "actual results" described in comment 0? I currently get all blank after step 4, Gecko/2007112605

This may be related to bug 318065...

I'm not surprised, as both bugs are set to block bug 318355. I wanted to try the patch on bug 318065 but it seems to have bitrotted...

> I wanted to try the patch on bug 318065 but it seems to have bitrotted... Heh, it was another patch of mine that bitrotted it. Updated patch posted in the bug...

It almost completely fixes all the cases except one: if you hit Undo on a new field, then the value silently changes to a newline (presumably the bogus BR node stops being bogus for some reason) although no input event is generated (the problem will show up more obviously after subsequent input).

> It almost completely fixes all the cases except one: if you hit Undo on a new > field, then the value silently changes to a newline (presumably the bogus BR > node stops being bogus for some reason) although no input event is generated > (the problem will show up more obviously after subsequent input). That sounds like 471319 / 471776

Maybe, but I don't see how emptytext is involved. Or is that just a symptom?

>That sounds like 471319 / 471776 Definitely 471319 > Maybe, but I don't see how emptytext is involved. Or is that just a symptom? Yes, for this case it's not involved - I've found that 471319 isn't really specific to emptytext or batched editing transactions, it's a more general problem. The editor post undo/redo code assumes that something interesting will happen during undo/redo: if you had a bogus node pre-undo/redo, it assumes there will have been text inserted, and marks the node as not bogus afterwards.

I think this was fixed long ago by a combination of bugs 318065 and 471319. Can anyone confirm?

Seems fixed to me.