User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:220.127.116.11pre) Gecko/20090814 SeaMonkey/2.0b2pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:18.104.22.168pre) 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
I see this in my 1.9.1 "trunk" build (recent source, mac).
Status: UNCONFIRMED → NEW
Ever confirmed: true
mcsmurf tells me this happens on windows too. This sort of makes the normal/preview views unusable :-(
OS: Mac OS X → All
Hardware: x86 → All
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.
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
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
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.
(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
blocking1.9.1: --- → ?
Component: Composer → Editor
Product: SeaMonkey → Core
QA Contact: composer → editor
Created attachment 396188 [details] [diff] [review] Proposed patch
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #396188 - Flags: review?(jst)
Yeah, I seem to have done a few copy & paste mistakes here.
(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
Whiteboard: regression from 432114
blocking1.9.1: .4+ → ?
status1.9.1: wanted → ---
Flags: blocking22.214.171.124+ → blocking126.96.36.199?
blocking1.9.1: ? → .4+
status1.9.1: --- → wanted
Flags: blocking188.8.131.52? → blocking184.108.40.206+
Whiteboard: regression from 432114 → [needs r=jst] regression from 432114
We should get an automated test that would have caught this regression.
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P1
Attachment #396188 - Flags: review?(jst) → review?(peterv)
Whiteboard: [needs r=jst] regression from 432114 → [needs r=peterv] regression from 432114
Comment on attachment 396188 [details] [diff] [review] Proposed patch Approved for 220.127.116.11 and 18.104.22.168, a=dveditz for release-drivers
Pushed changeset 01269eb934f5 to mozilla-central.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [needs r=peterv] regression from 432114
Pushed changeset d3b1d076e611 to releases/mozilla-1.9.1
status1.9.1: wanted → .4-fixed
Checked in nsHTMLEditor.cpp; new revision: 1.572; previous revision: 1.571
Pushed changeset a0497f2d30d6 to releases/mozilla-1.9.2
status1.9.2: --- → beta1-fixed
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:22.214.171.124pre) 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?
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.