510662 - On switching back from Tag-view to Normal- or Pre-view the tags are not removed

Status: RESOLVED FIXED

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

Description

[Rainer]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090814 SeaMonkey/2.0b2pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090814 SeaMonkey/2.0b2pre

The html-tags display sticks, I found no way to get rid of the tags.

Reproducible: Always

Steps to Reproduce:
1. write a few lines in Normal mode, including e.g. a new paragraph
2. switch to HTML Tags-mode to se the tags
3. return to normal mode. Voila: the tags are still there

Comment 1

[Stefan [:stefanh]]

I see this in my 1.9.1 "trunk" build (recent source, mac).

Comment 2

[Stefan [:stefanh]]

mcsmurf tells me this happens on windows too. This sort of makes the normal/preview views unusable :-(

Comment 3

[Stefan [:stefanh]]

If you start in normal mode, then switch to tag mode and back, the tags you've added are displayed in normal mode.

But, if you then continue working in normal mode, the new tags you add won't be displayed - not even if you switch to tag mode.

Comment 4

[Rainer]

Yes, it seems that after you switched to tag-mode once, view-refresh does not occure any more, whatever you do. Switching between views appears to be effect-less. Thanks for confirming the bug. I think this is a "show-stopper" - but could be overlooked as composer is in a less frequently used component. On the Mac though composer is quite special, there is hardly any other wysiwyg editor that allows to edit the source.

Comment 5

[Stefan [:stefanh]]

mcsmurf and I came up with this regression range:

works in http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9865a6c60c5b
does not works in http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9865a6c60c5b

In dates: works in 2009-02-26-00, but does not work in 2009-02-27-03

Comment 6

[Stefan [:stefanh]]

OK, so mcsmurf tested the 2009-02-27-01 build and it also appears to be broken. So, we have slightly better regression range:

Works in http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9865a6c60c5b
Broken in http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9b88ea41bcca

That is (m.o folder dates): Works in 2009-02-26-00, does not work in 2009-02-27-01

Comment 7

[Frank Wein [:mcsmurf]]

hg link: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?startdate=2009-02-26&enddate=2009-02-27+04%3A00
Bug 432114 might be related here as switching back to Normal view executes this code from editor.js:
1935           // Disable ShowAllTags mode
1936           editor.enableStyleSheet(kAllTagsStyleSheet, false);

Bug 432114 changed that function.

Comment 8

[Serge Gautherie (:sgautherie)]

(Ah, "Mid-air collision detected!", anyway:)

Stefan could you give exact directory name (like 2009-02-26-00-comm-central) and file name (like seamonkey-2.0b1pre.en-US.mac.dmg),
or even better the full buildID (like "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20090819 SeaMonkey/2.1a1pre")?

(In reply to comment #5)
> works in http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9865a6c60c5b
> does not works in http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9865a6c60c5b

These are the same url :-/

(In reply to comment #6)
> Works in http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9865a6c60c5b
> Broken in http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9b88ea41bcca

Assuming, these urls are reverse-ordered, the regression timeframe would be
http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=9b88ea41bcca&tochange=9865a6c60c5b
which is "Bug 476042 Integrate SPARC nanojit" only.

At first glance, this would seem unlikely:
Are the revs wrong?
Would not the regression rather be on comm-central?

Comment 9

[[e-mail]]

Attachment: Proposed patch

Comment 10

[Stefan [:stefanh]]

Yeah, I seem to have done a few copy & paste mistakes here.

Comment 11

[Stefan [:stefanh]]

(In reply to comment #10)
> Yeah, I seem to have done a few copy & paste mistakes here.
JFTR, should be:
works in http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f6d0ba597327
broken in http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9b88ea41bcca

Comment 12

[Serge Gautherie (:sgautherie)]

(In reply to comment #11)

Like comment 7 then:
http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=f6d0ba597327&tochange=9b88ea41bcca

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We should get an automated test that would have caught this regression.

Comment 14

[Daniel Veditz [:dveditz]]

Comment on attachment 396188 [details] [diff] [review]
Proposed patch

Approved for 1.9.1.4 and 1.9.0.15, a=dveditz for release-drivers

Comment 15

[[e-mail]]

Pushed changeset 01269eb934f5 to mozilla-central.

Comment 16

[[e-mail]]

Pushed changeset d3b1d076e611 to releases/mozilla-1.9.1

Comment 17

[[e-mail]]

Checked in nsHTMLEditor.cpp; new revision: 1.572; previous revision: 1.571

Comment 18

[[e-mail]]

Pushed changeset a0497f2d30d6 to releases/mozilla-1.9.2

Comment 19

[Al Billings [:abillings - ex-MoCo]]

I've verified this with a nightly Seamonkey 2.0 build using 1.9.1 (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090924 SeaMonkey/2.0pre).

There don't seem to be any Seamonkey builds using 1.9.0 at all. Any suggestions on how to verify it for 1.9.0?

Comment 20

[Rainer]

Coool, it's gone! Thank you!

Comment 21

[Al Billings [:abillings - ex-MoCo]]

Well, we still need to validate it for 1.9.0, theoretically, though I don't know if that code is used anywhere in 1.9.0.

Comment 22

[Frank Wein [:mcsmurf]]

IMHO this patch is trivial enough to just assume it work on 1.9.0 if it also works on trunk/branch.