Closed Bug 525359 Opened 15 years ago Closed 14 years ago

replying to an HTML message which includes a contenteditable div leaves Thunderbird compose unusable until restart (from incredimail for example)

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: premo12, Assigned: ehsan.akhgari)

References

(
URL
)

Details

(Keywords: testcase, Whiteboard: [gs] [has workarounds comments 19 and 36] [fixed by bug 616590])

Attachments

(1 file, 1 obsolete file)

Minimized testcase
444 bytes, message/rfc822
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 When "compose message in HTML format" is checked in account settings, you cannot see the text. I know there is text, if you hit "spell" it will show you the misspelled words. I also tried unchecking "automatic quote the original message when replying" and "include signature for replies" with the same result. I have tried to write and reply while in safe mode with the same results. I did re-downloaded and reinstalled with same results. I have not uninstalled and reinstalled. If I uncheck "compose message in html format" it works normally. Reproducible: Always Steps to Reproduce: 1.check compose message in html format 2.reply or create new message 3.type in message pane 4. hit spell check and see misspelled text Actual Results: no text in message pane hit spell check and see misspelled words
Michael, Please check your selections for HTML font color and background color in: Toola->Options->Composition->General tab
The text color is black and the background color is white under tools->options->composition->general tab. I changed text color to blue but still no text. I also used the "restore defaults", still no text as you type.
Version: unspecified → 3.0
I can assure you that there is nothing basically broken in HTML compose (I use it every day) So there is something different in your setup. Do you have any userchrome setup, or perhaps an extension (try starting in safe mode) http://kb.mozillazine.org/Safe_mode
I do not have any userchrome setup or any add ons. I did try starting in safe mode(as mentioned in my detail above) with the same result. I have using the 3 for a few months and this just started last night. The only thing that had changed last night was 2 windows updates. kb975375 and kb 972145.
After a reboot of computer it works until I try to reply to one certain email. I can forward the email to you if you would like to try to duplicate.
Sure, must be a style that sets a background, but that shouldn't persist through a session. My email addy is good.
Confirmed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091029 Shredder/3.0pre ID:20091029032301 There is no way that a received email should be able to lock up UI for HTML compose like this. Michael, we need a testcase eml to really document this, but I won't put that up unless you approve it. (privacy)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows Vista → All
Summary: cannot not see text when replying or writing a new message → cannot see text when replying or writing a new message after replying to a particular mail
If you can mask the email address, I approve. This is why we test.
Here is what is happening here. On reply, the quoted original message is not rendered. If you actually blindly type a reply and send, the reply shows below the quote. There are 2 remote images, but they don't seem to be pertinent to the problem. I'll dig deeper later to see if I can determine the actual tag that causing the problem. Testcase coming shortly after I double check that I obfuscated all the private data.
Attached file Reply data hidden (obsolete) —
Testcase eml
This is a virtual "bomb" for those that compose in HTML. Once you have tried to either Reply, or edit as new to it, then any further replies to any html message comes up blank until you restart TB. The <body> seems to pick up a styled background rather than an HTML background. color: rgb(0,0,0); background-color: rgb(255,255,255); Which would be OK if it worked. But styled backgrounds in general don't work very well, if at all in TB.
Attached file Minimized testcase —
The minimized testcase is |<div contenteditable="true">foo</div>| which I'd guess would be the result of copy-paste from an in-browser editor somewhere (or maybe the original message came from rather broken webmail).
Attachment #409418 - Attachment is obsolete: true
Yes, that div in the original message is indeed editable.(I wonder if I could convince my credit card co to provide that "feature" in the monthly statement :) It would be nice to know if that was a one in a million editing error, or some bug in a major mail-app, that could convince new TB users that HTML composition is broken in TB. In the meantime, I would think the thing to do would be to not parse the contenteditable attribute at all.
Keywords: testcase
So...|<div contenteditable="true">foo</div>|... puts us in full cssaware edit mode. Any editing inserts styles and not html. The last time that happened, this was the fix: Index: nsHTMLEditor.cpp =================================================================== RCS file: /cvsroot/mozilla/editor/libeditor/html/nsHTMLEditor.cpp,v retrieving revision 1.490 diff -p -u -r1.490 nsHTMLEditor.cpp --- nsHTMLEditor.cpp 18 Aug 2003 05:18:05 -0000 1.490 +++ nsHTMLEditor.cpp 21 Aug 2003 16:49:37 -0000 @@ -445,7 +445,7 @@ NS_IMETHODIMP nsHTMLEditor::SetFlags(PRUint32 aFlags) { if (!mRules) { return NS_ERROR_NULL_POINTER; } - mCSSAware = ((aFlags & nsIPlaintextEditor::eEditorNoCSSMask) == 0); + mCSSAware = ((aFlags & (eEditorNoCSSMask | eEditorMailMask)) == 0); return mRules->SetFlags(aFlags); }
Laurent anything you can do ?
Summary: cannot see text when replying or writing a new message after replying to a particular mail → replying to an HTML message which includes a content-editable div leaves Thunderbird compose unusable until restart
If it helps track this - I have experienced the same issue TB 3 RC1 with an email sent by someone using Incredimail (eek) Based on what I have read here, I'm guessing because of this line: <TABLE style=3D"MARGIN: 3px; WIDTH: 100%; FONT-FAMILY: Times New Roman; F= ONT-SIZE: 12pt" tabIndex=3D-1 contentEditable=3Dtrue width=3D"100%"> just wanted to be sure you knew it wasn't only DIV's that were causing this.
Nominated for blocking 3.0 as using the content editable tag could be used maliciously.(You like to compose in html...try replying to this) Judging from some of the plaintext vs html flamewars I've seen in the past, I wouldn't put it past some folks.
Flags: blocking-thunderbird3?
Some additional observations: This is not a new condition, I can duplicate in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080915030813 Shredder/3.0b1pre ID:20080915030813 Looks like a possible work-around after you get locked up for html composition, is to open a plaintext compose window, then exit compose. IMO we still should target some future milestone for bullet-proofing.
While this is unfortunate, we tend not to block on DOS bugs, largely because there are lots of them and they're hard to defend against. That said, if there's a sufficiently simple fix, we'd certainly consider it for the branch. Setting flags appropriately.
status-thunderbird3.0: --- → wanted
Flags: blocking-thunderbird3? → blocking-thunderbird3-
Just a note that the case of the <table> with editable true was one where the person who sent the mail simply composed a normal message using incredimail (nothing special) and intended no ill will. I tried to reply and hit the bug - it was my first reply with TB 3 and I actually thought it was broken in some way. If a normal mail from incredimail users always has this flag set - it's actually a fairly serious issue for anyone trying to reply to them.
A good point. Adding qawanted in the hopes that someone will download and test Incredimail to see if that actually is the default.
Keywords: qawanted
I'm game for the Incredimail qa Been there before it seems, they even saved my inbox from 2004 :) Their html toolbar is rather simple, no way to Insert a table, (they do that for you) actually, it's not as much "tag soup" as the last time I tried it. And not nearly as bad as MSword formatted html. Results: Sent in Incredimail, and received in TB 3-4 messages using the provided templates. No contenteditable tag appeared. There are "user provided" templates that might be suspect (didn't try them) Would test some more, but it seems Incredimail uses my real mail domain and since I'm using Pop3, don't want to lose any mail. Just as an aside, they do provide an option to allow javascript, a couple of my old templates were in my old inbox there...worked fine.
Keywords: qawanted
I contacted the people sending emails that had the issue to ask what they were using - it always happens when they add their own image to their signature in incredimail no image and there was no contenteditable tag - I tried it and got the same result. It's all moot to some extent - TB really shouldn't bork just because that tag is there regardless of why.
I would think that it would be fairly common for an Incredimail user to place an image in a signature.(since rich text capability is probably why they are using it in the first place) Requesting blocking (3.1)
Flags: blocking-thunderbird3.1?
It would be great to get this, and while it could theoretically be common for Incredimail, I have yet to see evidence that it's common for Thunderbird users as whole. If this were the last bug standing for 3.1, we wouldn't hold the release for it.
Flags: blocking-thunderbird3.1? → blocking-thunderbird3.1-
(In reply to comment #28) > It would be great to get this, and while it could theoretically be common for > Incredimail, I have yet to see evidence that it's common for Thunderbird users > as whole. If this were the last bug standing for 3.1, we wouldn't hold the > release for it. doesn't seem to be too common on Get Satisfaction: 1. 10 people in this thread http://gsfn.us/t/n0em 2. 4 people in this thread http://gsfn.us/t/ocw5 but as always may have missed a few because people don't tag threads consistently with helpful :-) tags like "incredimail" Still, all in all, not on the order of Kaspersky or our SMTP issues in 3.0.x
(In reply to comment #30) Two URLs at once do not work at this page: "http://gsfn.us/t/n0em http://gsfn.us/t/ocw5". I mean URL link in the Bug 525359 headers. Here is the 3rd: http://getsatisfaction.com/mozilla_messaging/topics/cannot_type_message_body For me, this bug is quite serious.
This is a major interoperability problem (incredimail/Thunderbird) [GS} http://getsatisfaction.com/mozilla_messaging/topics/replying_to_emails_in_thunderbird I realize that there is nobody proficient/interested in the editor code or the advancement of the use of rich text in email, but the reality can't be denied: Folks want to use it, and we are ignoring it. Someone needs to step up here and actually learn the core code. Remember when the Marquee tag was resisted for those many months, then the decision was finally made: It's there, so we should support it. HTML mail is here to stay, Incredimail, is here to stay, blogs, and social networks are here to stay, if we don't react to that need, TB will wither away. (sorry for the editorial)
Same Problem here. Our company's support department gets hundreda of mails every day. Once in a week TB3 stops working because of an incredimail from a customer. The solution for the support department: Copy the mail adress of the customer, restart TB, start writing a new mail to the copied adress (without quoting), then delete the original mail (not to fall into that hole again) and then restarting TB again, as deleting displayed the mail again... :-( Not really satisfying.
KaZe, do you have any theories about what might be going on here and how hard it would likely be to fix?
Summary: replying to an HTML message which includes a content-editable div leaves Thunderbird compose unusable until restart → replying to an HTML message which includes a contenteditable div leaves Thunderbird compose unusable until restart
Here are a few alternatives that might ease the pain. To get out of the HTML compose lockout, just open a plaintext compose window. Shift+reply to the problematic message should do it. If you must (or just want to) reply quoted to the contenteditable message.. Temporarily select View>>Message body as..simple HTML This sanitizes the message to ignore the contenteditable tag (and others) but does not restrict your ability to reply with whatever HTML you desire. Of course, the use of conteneditable in your composition is not recommended :)
Nice find, Joe; thanks! I wonder if that will help in debugging the problem too...
Whiteboard: [gs] → [gs] [has workaround]
Hi all: I can confirm that https://bugzilla.mozilla.org/attachment.cgi?id=409465 reproduces the bug in Thunderbird 3.0.3 Mac OS X 10.5.8 and that Joe's workarounds indeed workaround it. We are now up to 57 people who have this problem in Get Satisfaction (by adding the number of metoos for the 4 GS threads (assuming they are the same problem) http://gsfn.us/t/n0em http://gsfn.us/t/ocw5 http://gsfn.us/t/p0vt http://gsfn.us/t/pof0 Based on the number of people with the problem and the fact that dmose unflagged it for 3.1 and there are workarounds, I would like to nominate this bug for thunderbird 3.1 "wanted" (because if it's "just" a fix to neuter contenteditable html attributes it sounds doable), but there is no such flag status anymore right dmose? Joe I tried but could not reproduce the problem with Incredimail 2.0 on Windows 7 using the following steps: 1. create a signature with an image of my face in incredimail 2. compose an email with that signature in incredimail using my Incredimail account with Hotmail as the mail provider 3. send out the email via Hotmail's SMTP using incredimail 4. open the received email in Thunderbird and click reply: RESULT: in Mac Thunderbird 3.0.3 Mac OS X 10.5.8 is that I can reply to the email without reproducing the problem, i.e. the reply is not blank and you can see the cursor Joe: what mail provider did you use and what were your steps to reproduce?
URL: http://gsfn.us/t/n0em http://gsfn.us/... → http://gsfn.us/t/n0em http://gsfn.us/...
status-thunderbird3.1: --- → rc1-fixed
(In reply to comment #38) > We are now up to 57 people who have this problem in Get Satisfaction (by adding > the number of metoos for the 4 GS threads (assuming they are the same problem) > http://gsfn.us/t/n0em http://gsfn.us/t/ocw5 http://gsfn.us/t/p0vt > http://gsfn.us/t/pof0 Can you offer some context around the 57? How does that compare to other problems that you think are critical? Is it believed that they're all from interactions with Incredimail? > Based on the number of people with the problem and the fact that dmose > unflagged it for 3.1 and there are workarounds, I would like to nominate this > bug for thunderbird 3.1 "wanted" (because if it's "just" a fix to neuter > contenteditable html attributes it sounds doable), but there is no such flag > status anymore right dmose? There's a status-3.1: wanted state, which I've set.
status-thunderbird3.1: rc1-fixed → wanted
Flags: wanted-thunderbird+
(In reply to comment #39) > (In reply to comment #38) > > We are now up to 57 people who have this problem in Get Satisfaction (by adding > > the number of metoos for the 4 GS threads (assuming they are the same problem) > > http://gsfn.us/t/n0em http://gsfn.us/t/ocw5 http://gsfn.us/t/p0vt > > http://gsfn.us/t/pof0 > > Can you offer some context around the 57? How does that compare to other > problems that you think are critical? > > Is it believed that they're all from interactions with Incredimail? dmose, I've been experiencing this problem, but it hasn't been from any interaction with Incredimail. After investigation, a client of ours has an email template which they use with Outlook 2007 which contains contenteditable="true", which seems to define the area of the template which is editable.
I would like to reiterate that, for me, this issue of invisible text is not restricted to use of Incredimail or to only Replying to an email. As I stated in bug 540705: I am using TB 3.0.1 with Comcast on a Win2K machine. When I compose a NEW email, the cursor moves but nothing appears. The bug seems to be in the "Variable Width" font. Before I start typing, if I change "Variable Width" to "Times" I am then able to see what I'm typing. The problem also exists in all my SENT mail; i.e., the text is invisible because it was always composed using the "Variable Width" font. To read what I've sent, I have to first click Reply or Forward, then highlight all the text, then change the font to "Times". I do compose in HTML, but use neither a background nor a signature. This problem did not exist in TB2.
1 more user on GS: "Jonathan" has the problem at http://gsfn.us/t/ro9f Jonathan says "The content did not come from incredimail users as I experienced the problem when replying to several different messages from different people I think it is rather unlikely that they all were using incredimail. To be clear, the problem I saw was after I replied. I could see the body of the message I was responding to. It was all other messages after the reply that were not displaying correctly."
(In reply to comment #42) > I would like to reiterate that, for me, this issue of invisible text is not > restricted to use of Incredimail or to only Replying to an email. As I stated > in bug 540705: > > I am using TB 3.0.1 with Comcast on a Win2K machine. When I compose a NEW > email, the cursor moves but nothing appears. The bug seems to be in the > "Variable Width" font. Before I start typing, if I change "Variable Width" > to "Times" I am then able to see what I'm typing. > > The problem also exists in all my SENT mail; i.e., the text is invisible > because it was always composed using the "Variable Width" font. To read what > I've sent, I have to first click Reply or Forward, then highlight all the text, > then change the font to "Times". > > I do compose in HTML, but use neither a background nor a signature. > > This problem did not exist in TB2. hi Mac: I think you have different problem. Is it related to NVIDA video drivers being out of date, i.e. http://gsfn.us/t/can5 ? I cannot reproduce your problem. Here's what I did with Thunderbird 3.0.3 and Windows 7: 1. compose an email in HTML w/o background and signature but with Variable Width font - I can compose and send this email with no problem with the cursor or visibility of what I am typing 2. I then reply this Variable Width Font by selecting it in my Sent Folder and the clicking reply - Again I can compose and send this email with no problem with the cursor or visibility of what I am typing.
Hi, No, I don't think that was the case, as I've always tried to keep my drivers up to date and never experienced the display issue you pointed out. However, it may all be moot now for me, as my HD just died, leaving me unable to pursue a fix. I guess it's finally time for a new machine -- one way to resolve the problem, I suppose. :( Thanks for your help.
I have multiple e-mails here that show this behaviour. For so far I checked, not all have headers that would indicate IncrediMail as the sending client. Also, the "View>>Message body as..simple HTML" workaround does not work for all problematic e-mails, only some. I would attach the emails, if it was not so much work to make sure I do not include any personal data. Is there a tool for this?
(In reply to comment #30) >.. > Still, all in all, not on the order of Kaspersky or our SMTP issues in 3.0.x ... which are now fairly well gone. IMO this should not be allowed to linger further, and be targeted for one of the next couple point releases of 3.1. - count in gfsn articles is up to 90+ (though no doubt there is some double counting) - workaround is not obvious and problem impacts primary UI - issue is not limited to incredimail - potential patch appears to be trivial
blocking-thunderbird3.1: --- → ?
Whiteboard: [gs] [has workaround] → [gs] [has workaround comment 19]
Whiteboard: [gs] [has workaround comment 19] → [gs] [has workarounds comments 19 and 36]
(In reply to comment #48) > (In reply to comment #30) > >.. > > Still, all in all, not on the order of Kaspersky or our SMTP issues in 3.0.x > > ... which are now fairly well gone. IMO this should not be allowed to linger > further, and be targeted for one of the next couple point releases of 3.1. > - count in gfsn articles is up to 90+ (though no doubt there is some double > counting) > - workaround is not obvious and problem impacts primary UI > - issue is not limited to incredimail > - potential patch appears to be trivial I agree 100%. You guys have been discussing this for ten months now. If the patch appears to be trivial, fix the darn thing already! I know I, and probably most everybody else who's encountered this issue, will not upgrade to v3 until it is fixed. You have to know that there have been first-time users who've encountered this and gone back to IE or whatever -- and yet you continue to jawbone about it interminably. Don't you understand that not being able to compose an email in an email app should be considered a BLOCKER?!
lol -- I meant Outlook, not IE. :)
http://gsfn.us/t/15w3y another example?
Summary: replying to an HTML message which includes a contenteditable div leaves Thunderbird compose unusable until restart → replying to an HTML message which includes a contenteditable div leaves Thunderbird compose unusable until restart (from incredimail for example)
Just got Thunderbird 3.1.5 and checked for this bug and was easily able to reproduce it with my test message. Please resolve this issue if at all possible. P.S. - The disabling html compose workaround did take care of it but we shouldn't have to do that.
To the developers: setting designMode="off" and then reset designMode="on" on loading the body seems to fix the problem. I made a test and this code seems to solve: ------ function test() { var msgDoc = document.getElementById("content-frame").contentDocument; msgDoc.designMode = "off"; msgDoc.designMode = "on"; } window.addEventListener("DOMContentLoaded", test, true); ----- I hope that this can help.
Edit: it seems to be sufficient msgDoc.designMode = "on";
Ehsan, do the above findings about designMode affecting this bug make sense to you?
(In reply to comment #64) > David, could this be related? > http://mxr.mozilla.org/comm-1.9.2/source/mozilla/content/html/document/src/nsHTMLDocument.cpp#3358 Possibly, but I'm not knowledgeable about this code. Someone could try your change combined with commenting out that code and see if the bug is still fixed, to verify if that's the reason your change works.
In the meantime, I've insert the fix in the last version of QuoteAndComposeManager extension (0.3.18), so that everyone can test the workaround.
(In reply to comment #66) > In the meantime, I've insert the fix in the last version of > QuoteAndComposeManager extension (0.3.18), so that everyone can test the > workaround. I just tested this and it works well for me! Thanks ;)
Comment 15 seems to be the right way to fix this bug. I'd review a patch which does that and comes with a test before you can say Jack Robinson. :-) Is anyone up for that?
Eshan, I'd like to help, but I'm not into C++ enough to be able to do it. Of course adding some javascript code to implement the "designMode" hack is trivial, but I guess that it's not an acceptable fix and I don't think you need help for this :-) About comment#15 I've a doubt: as reported in comment#1 and as I've tested personally inspecting the DOM of the message, the text is in effect inserted in the DOM message, but it's not showed in editor. That said, the assumption "Any editing inserts styles and not html" is correct or not?
(In reply to comment #69) > Eshan, I'd like to help, but I'm not into C++ enough to be able to do it. > Of course adding some javascript code to implement the "designMode" hack is > trivial, but I guess that it's not an acceptable fix and I don't think you need > help for this :-) > > About comment#15 I've a doubt: as reported in comment#1 and as I've tested > personally inspecting the DOM of the message, the text is in effect inserted in > the DOM message, but it's not showed in editor. > That said, the assumption "Any editing inserts styles and not html" is correct > or not? If you blindly Insert>>Image while in the indeterminate state, you get styled width and height. <img style="width: 28px; height: 28px;" alt="" src="cid:part1.05020204.04090601@bellatlantic.net"> Which was happening in the "way back when" problem I referenced in comment 15 BTW I had to test in TB 3.1 as there is a crash problem now when trying to test in current trunk, when contenteditable is in the composition.
Blake, you wanna give this a shot sometime at the office?
(I really need to test this to make sure if comment 15 is the right fix)
My patch in bug 616590 will fix this problem. We need Litmus tests in Thunderbird (or automated one, if somebody wants to write them) though.
Assignee: nobody → ehsan
Flags: in-litmus?
Whiteboard: [gs] [has workarounds comments 19 and 36] → [gs] [has workarounds comments 19 and 36] [will be fixed by bug 616590]
This should now be fixed by bug 616590. If not, please reopen.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [gs] [has workarounds comments 19 and 36] [will be fixed by bug 616590] → [gs] [has workarounds comments 19 and 36] [fixed by bug 616590]
That's great, thanks so much, Ehsan! I expect this will make a bunch of users significantly less frustrated.
For completeness, I got latest, built TB trunk, and re-ran the test, and it did fix the issue reported here. Now if I could only figure out why I can't access window.arguments from my chrome html file… :) Thanks, Blake.
Status: RESOLVED → VERIFIED
(removing tracking flags as this is now being tracked for branch in bug 616590).
blocking-thunderbird3.1: ? → ---
status-thunderbird3.0: wanted → ---
status-thunderbird3.1: wanted → ---
Depends on: 625740
Sorry but some user still see this bug in Thunderbird 3.1.7 (on Geckozone's forum). So do you planned to fix it for 3.1.x?
As mentioned in bug 616590, where this was fixed, it is currently only available in Thunderbird 3.3.
I will mention again what was said in comment 66 The fix for this bug is included in the quote and compose manager extension. Cameleon, For folk using 3.1.x and 3.0.x installing the extension really does fix the problem, as well as unstable fonts and a couple of other bugs.
> I will mention again what was said in comment 66 The fix for this bug is > included in the quote and compose manager extension. If anyone has a doubt: he's talking about the Thunderbird extension called "QuoteAndComposeManager", that can be just installed, without a later configuration. Thanks! This also fixed the problem for us in Thunderbird 3.1.9.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: