Using the trunk build 20020910 on winxp and linux when you use the context menu on a email address in the header of a viewed message the compose window comes up in plain text even if the identity is set for html compose. This is regression from the released branch build. 1. Launch app 2. Have all your mail accounts set to use HTML compose 3. Open a mail message (I opened both a plain text and html compose msg) in the message pane, 4. Right mouse click on one of the recipients. Result: The compose window comes up in plaintext compose Expected: In this case, since I had all my mail accounts including the default account set to HTML compose, I should have has an HTML compose window.

.

I see this with mailto links withing a mail message too.

I see this in Win 2000 too (2002092511)

This is true from mailto links in web pages also, such as those in Bugzilla

*** Bug 176504 has been marked as a duplicate of this bug. ***

*** Bug 180453 has been marked as a duplicate of this bug. ***

*** Bug 183084 has been marked as a duplicate of this bug. ***

*** Bug 183359 has been marked as a duplicate of this bug. ***

*** Bug 183375 has been marked as a duplicate of this bug. ***

*** Bug 183233 has been marked as a duplicate of this bug. ***

*** Bug 183603 has been marked as a duplicate of this bug. ***

The web page mailto: behaviour is a security feature, to stop malicious HTML being embedded into the message.

Is there a way to switch Composer manually to HTML mode (i.e. a menu command)? This might be a satisfactory workaround, especially for web page mailto links.

Security Behavior? There isn't going to be any extra HTML that I didn't already trigger when I viewed the message, is there?

Is the security concern that an html mailto: link can carry text content as a parameter? If so, it would seem smarter to simply limit the treatment of importing those parameters to plain text and ensure that no html is included, the same way keyboard text is limited. There is no way to type in html tags, for example.

*** Bug 184125 has been marked as a duplicate of this bug. ***

taking all of varada's bugs.

This bug is probably due to changes made in bug 90728, "mailto: link treats body= as HTML".

Mail triage team: nsbeta1+/adt2

*** Bug 191069 has been marked as a duplicate of this bug. ***

Comment on attachment 112986 [details] [diff] [review] Proposed patch I think this should open the compose window correctly; I thought it would be nice to use the full name as displayed, not just the address.

Comment on attachment 112986 [details] [diff] [review] Proposed patch r=cavin.

Comment on attachment 112986 [details] [diff] [review] Proposed patch sr=sspitzer nice, neil.

over to neil. since it's a regression, how about 1.3 beta? I'll seek approval

Comment on attachment 112986 [details] [diff] [review] Proposed patch a=asa (on behalf of drivers) for checkin to 1.3beta.

Fix checked in. While writing this patch I noticed that the new message (both before and after) always uses the default identity; is that another regression?

Regression bug 191452.

"While writing this patch I noticed that the new message (both before and after) always uses the default identity; is that another regression?" we'd want to use the proper, current identity. can you spin up a new bug about that?

per comment 29 : bug 191732 was opened for that.

*** Bug 189407 has been marked as a duplicate of this bug. ***

If i click a mailto link in browser, the composer comes up in plaintext mode (current CVS, Linux. According to bug 190120, users on both Linux, Mac and Win2000 are still seeing this bug. What exactly was fixed here? Did something regress again?

> What exactly was fixed here? The "links" in the message header pane.

Sorry - then a lot of bugs have mistakenly been dup'ed against this bug. I reopened them and dup'ed against bug 190120 instead.

Those who voted for this bug believing it was about mailto links in browser (and not only mailto in a mailnews message header) - please move your votes to bug 190120 instead: FLLJimmB@earthlink.net castaban@yahoo.ca jc@thp.org

Using trunk builds 20030303 on winxp macosx and linux and the original scenario: mailto links in message header, this is fixed. Verified Note all incorrectly dup'd bugs have been correctly dup'd to 190120.

I see this again in 1.4b (20030507). The mailto: link opens a plain text compose window disregarding the mail composition settings.

Using branch build 20030617 (1.4) this is still working as fixed. Note to nebigredfan@netscape.net in comment 37 If you click on a mailto link within a mail message in an account other than the default mail account or from a browser page, it will use the identity and compose format of the default account (it does not use the identity of the account where you are reading the message). However, If you right click on an email address in a header of a mail message to select "Compose Mail to" it will use the identity of the account from which you are reading the message. This still works correctly with the 20030617 branch build.