147625 - strange characters in message composer title/subject (was Strange undo/redo interaction with oninput handlers)

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect, P2)

Description

[[e-mail]]

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

Comment 1

[[e-mail]]

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...

Comment 2

[[e-mail]]

Attachment: Test Case

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

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 4

[Joel Gedalius]

Why hasn't this been fixed yet?

Comment 5

[[e-mail]]

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

Comment 6

[Wayne Mery (:wsmwk)]

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

Comment 7

[[e-mail]]

(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.

Comment 8

[Wayne Mery (:wsmwk)]

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 

Comment 9

[Graeme McCutcheon [:graememcc]]

This may be related to bug 318065...

Comment 10

[[e-mail]]

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...

Comment 11

[Graeme McCutcheon [:graememcc]]

> 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...

Comment 12

[[e-mail]]

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).

Comment 13

[Graeme McCutcheon [:graememcc]]

> 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

Comment 14

[[e-mail]]

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

Comment 15

[Graeme McCutcheon [:graememcc]]

>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.

Comment 16

[Graeme McCutcheon [:graememcc]]

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

Can anyone confirm?

Comment 17

[[e-mail]]

Seems fixed to me.