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

VERIFIED FIXED

Status

Thunderbird
Message Compose Window
--
major
VERIFIED FIXED
8 years ago
6 years ago

People

(Reporter: Michael Primeaux, Assigned: Away for a while)

Tracking

({testcase})

Dependency tree / graph
Bug Flags:
wanted-thunderbird +
blocking-thunderbird3 -
blocking-thunderbird3.1 -
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment, 1 obsolete attachment)

444 bytes, message/rfc822
Details
(Reporter)

Description

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

Comment 1

8 years ago
Michael,
Please check your selections for HTML font color and background color in:
Toola->Options->Composition->General tab
(Reporter)

Comment 2

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

Updated

8 years ago
Version: unspecified → 3.0

Comment 3

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

Comment 4

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

Comment 5

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

Comment 6

8 years ago
Sure, must be a style that sets a background, but that shouldn't persist through a session. My email addy is good.

Comment 7

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

Comment 8

8 years ago
If you can mask the email address, I approve. This is why we test.

Comment 9

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

Comment 10

8 years ago
Created attachment 409418 [details]
Reply data hidden

Testcase eml

Comment 11

8 years ago
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.
Created attachment 409465 [details]
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

Comment 13

8 years ago
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.
Probably bug 436703.
Keywords: testcase

Comment 15

8 years ago
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 ?

Updated

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

Comment 17

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

Comment 18

8 years ago
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?

Comment 19

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

Comment 21

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

Comment 23

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

Updated

8 years ago
Duplicate of this bug: 535418

Updated

8 years ago
Duplicate of this bug: 542012

Comment 26

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

Comment 27

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

Updated

8 years ago
Duplicate of this bug: 543032
(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

Comment 31

8 years ago
(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.

Comment 32

8 years ago
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)

Comment 33

8 years ago
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
Duplicate of this bug: 550788

Comment 36

8 years ago
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?
(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+

Comment 40

8 years ago
(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.

Updated

8 years ago
Duplicate of this bug: 540705

Comment 42

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

Comment 45

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

Updated

8 years ago
Duplicate of this bug: 559694

Comment 47

8 years ago
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?

Comment 48

7 years ago
(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]

Comment 49

7 years ago
http://getsatisfaction.com/mozilla_messaging/topics/problem_sending_a_reply?topic_tools=open

Updated

7 years ago
Duplicate of this bug: 543032

Updated

7 years ago
Whiteboard: [gs] [has workaround comment 19] → [gs] [has workarounds comments 19 and 36]

Updated

7 years ago
Duplicate of this bug: 584361

Comment 52

7 years ago
(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?!

Comment 53

7 years ago
lol -- I meant Outlook, not IE. :)
Duplicate of this bug: 541162

Updated

7 years ago

Comment 55

7 years ago
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)
Duplicate of this bug: 605354

Comment 57

7 years ago
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.
Another example of this issue on French forums: http://www.geckozone.org/forum/viewtopic.php?f=4&t=86767&p=589421#p589417
Duplicate of this bug: 605820

Updated

7 years ago
Duplicate of this bug: 611447
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";

Comment 63

7 years ago
Ehsan, do the above findings about designMode affecting this bug make sense to you?
David, could this be related?
http://mxr.mozilla.org/comm-1.9.2/source/mozilla/content/html/document/src/nsHTMLDocument.cpp#3358

Comment 65

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

Comment 67

7 years ago
(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 ;)
(Assignee)

Comment 68

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

Comment 70

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

Comment 71

7 years ago
Blake, you wanna give this a shot sometime at the office?
(Assignee)

Comment 72

7 years ago
(I really need to test this to make sure if comment 15 is the right fix)

Updated

7 years ago
Duplicate of this bug: 615916
Depends on: 616590
(Assignee)

Comment 74

7 years ago
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]
(Assignee)

Comment 75

7 years ago
This should now be fixed by bug 616590.  If not, please reopen.
Status: NEW → RESOLVED
Last Resolved: 7 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.
https://litmus.mozilla.org/show_test.cgi?id=15020
Flags: in-litmus? → in-litmus+
Status: RESOLVED → VERIFIED
Duplicate of this bug: 618729
(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?

Comment 82

7 years ago
As mentioned in bug 616590, where this was fixed, it is currently only available in Thunderbird 3.3.

Comment 83

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

Updated

7 years ago
Duplicate of this bug: 637647

Comment 85

7 years ago
> 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.
Duplicate of this bug: 552972

Updated

6 years ago
Duplicate of this bug: 613991

Updated

6 years ago
Duplicate of this bug: 578766
You need to log in before you can comment on or make changes to this bug.