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

RESOLVED FIXED in mozilla1.9.3a1

Status

()

Core
Editor
P1
major
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Rainer, Assigned: neil@parkwaycc.co.uk)

Tracking

({fixed1.9.0.15, regression, verified1.9.1})

Trunk
mozilla1.9.3a1
fixed1.9.0.15, regression, verified1.9.1
Points:
---
Bug Flags:
blocking1.9.2 +
blocking1.9.0.15 +
wanted1.9.0.x +
in-testsuite ?

Firefox Tracking Flags

(status1.9.2 beta1-fixed, blocking1.9.1 .4+, status1.9.1 .4-fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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

9 years ago
I see this in my 1.9.1 "trunk" build (recent source, mac).
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

9 years ago
mcsmurf tells me this happens on windows too. This sort of makes the normal/preview views unusable :-(
Flags: blocking-seamonkey2.0b2?
OS: Mac OS X → All
Hardware: x86 → All

Comment 3

9 years ago
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.
(Reporter)

Comment 4

9 years ago
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.
Severity: major → critical
Priority: -- → P2

Comment 5

9 years ago
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

9 years ago
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
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.

Updated

9 years ago
Blocks: 432114
(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?
Severity: critical → major
Priority: P2 → --
Version: unspecified → Trunk
(Assignee)

Updated

9 years ago
blocking1.9.1: --- → ?
Component: Composer → Editor
Flags: blocking1.9.2?
Flags: blocking1.9.0.15?
Flags: blocking-seamonkey2.0b2?
Keywords: regression
Product: SeaMonkey → Core
QA Contact: composer → editor
(Assignee)

Comment 9

9 years ago
Created attachment 396188 [details] [diff] [review]
Proposed patch
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #396188 - Flags: review?(jst)

Comment 10

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

Comment 11

9 years ago
(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
blocking1.9.1: ? → .4+
status1.9.1: --- → wanted
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.15?
Flags: blocking1.9.0.15+
Whiteboard: regression from 432114
blocking1.9.1: .4+ → ?
status1.9.1: wanted → ---
Flags: blocking1.9.0.15+ → blocking1.9.0.15?
blocking1.9.1: ? → .4+
status1.9.1: --- → wanted
Flags: blocking1.9.0.15? → blocking1.9.0.15+
Whiteboard: regression from 432114 → [needs r=jst] regression from 432114
We should get an automated test that would have caught this regression.
Flags: in-testsuite?
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P1
(Assignee)

Updated

9 years ago
Attachment #396188 - Flags: review?(jst) → review?(peterv)

Updated

9 years ago
Whiteboard: [needs r=jst] regression from 432114 → [needs r=peterv] regression from 432114

Updated

9 years ago
Attachment #396188 - Flags: superreview+
Attachment #396188 - Flags: review?(peterv)
Attachment #396188 - Flags: review+
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
Attachment #396188 - Flags: approval1.9.1.4+
Attachment #396188 - Flags: approval1.9.0.15+
(Assignee)

Comment 15

9 years ago
Pushed changeset 01269eb934f5 to mozilla-central.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [needs r=peterv] regression from 432114
(Assignee)

Comment 16

9 years ago
Pushed changeset d3b1d076e611 to releases/mozilla-1.9.1
status1.9.1: wanted → .4-fixed
(Assignee)

Comment 17

9 years ago
Checked in nsHTMLEditor.cpp; new revision: 1.572; previous revision: 1.571
Keywords: fixed1.9.0.15
(Assignee)

Comment 18

9 years ago
Pushed changeset a0497f2d30d6 to releases/mozilla-1.9.2
status1.9.2: --- → beta1-fixed
Target Milestone: --- → mozilla1.9.3a1
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?
Keywords: verified1.9.1
(Reporter)

Comment 20

9 years ago
Coool, it's gone! Thank you!
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.
IMHO this patch is trivial enough to just assume it work on 1.9.0 if it also works on trunk/branch.
You need to log in before you can comment on or make changes to this bug.