550414 - mailto: links open Rich Text Editor instead of plain text specified in account settings

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[Joseph Oster]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2

This is new behavior, never used to work this way!  I prefer to send plain text emails and have my account settings "Compose messages in HTML format" unchecked (under Composition & Addressing).  Works as expected when I click the "Write" button in Thunderbird, but when I click a mailto: link on a web page, it always opens the HTML-based Rich Text Editor instead.

In the Rich Text Editor, 'Options | Format | Plain Text Only" makes the RTE buttons disappear bu the email message is still HTML with unwanted formatting, boldface, etc.

Reproducible: Always

Steps to Reproduce:
1. "Tools | Account Settings | Composition & Addressing" - "Compose messages in HTML format" unchecked
2. click any mailto: link
3. Compose window opens in RTE/HTML editor instead of plain text format

Comment 1

[Ludovic Hirlimann [:Usul]]

Was this the case already in 2.x ?

Comment 2

[Joseph Oster]

As I said, this is new behavior, not sure exactly when it started - might be about the same time I got a new laptop (a month ago), running Windows 7 instead of Windows Vista?

Comment 3

[Michael A. Koenecke]

Happens on my machines too (desktop & laptop). Very annoying. Runningf WIndows XP Home.

Comment 4

[Martey Dodoo]

I can confirm as well on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 and Thunderbird/3.1.3.

Comment 5

[Joe Sabash [:JoeS1]]

I'm not able to reproduce this in:
Lanikai/3.1.5pre or Thunderbird/3.3a1pre
Using Win2k at the moment.
It seems to follow the pref regardless of address book format prefs.

Comment 6

[Michael A. Koenecke]

Why exactly is this listed as "unconfirmed?" This is one of the most annoying bugs in Thunderbird, and is definitely present in 3.1.7. I use a text signature, and whenever I try to send e-mail via clicking a link, whether out of Firefox or Thunderbird, the (*)&%#()#&$* HTML composer window pops up, showing a jumbled signature at the bottom. Seems to me it is following some process initiated by Windows (mailto: link); if someone could only figure out how that setting can be changed this problem could be fixed.

Comment 7

[EEFranklin]

I can also confirm it does not follow the preferences on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10.

To the best of my memory, it has been like this for a long time (years?), but don't know any earlier version numbers.  It is quite annoying, but I have gotten in the habit of copying the email address, open a new message from TB, and paste the address.

Comment 8

[Bernd]

Confirmed in TB3.1.10 (windows;u;NT5.1;en-Us;rv:1.9.2.17) Gecko/20110414 
in combination with
FF 4.0.1 / Win7 64 Bit

Still there and annoying

Comment 9

[Slater]

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11

the problem seemed to arise from a erroneous default account setting in prefs.js. here's how i fixed it.

1. close Thunderbird / Icedove
2. make a backup copy of prefs.js in user directory (on Linux .icedove/xxxxxxxx.default) and open it in an editor.
3. lines that start with
   user_pref("mail.account.account1.server", "server1");
   list the servers of the mail accounts. There may be unused ones.
4. find line
   user_pref("mail.accountmanager.defaultaccount", "account1");
   and identify to which server this account is assigned to, e.g.
   user_pref("mail.account.account1.server", "server1");
5. from an entry like
   user_pref("mail.server.server1.directory", "$HOME/.icedove/xxxxxxxx.default/ImapMail/yourmailserver.com");
   identify if this folder exists and if this is your preferred default account.
   if not: assign a different default account in
   user_pref("mail.accountmanager.defaultaccount", "account2");

6. save prefs.js and restart thunderbird/icedove.

Comment 10

[Michael A. Koenecke]

That's an interesting thought, so I checked: unfortunately, all my servers and accounts are set correctly and point to real directories. Perhaps there is something in IceDove which allows this to work - but I cannot try IceDove, as I'm on Windows.

Comment 11

[sphakka]

Hello,

I had this problem with SeaMonkey-2.x. The real issue might be with the default account pointing to "localfoldersserver" instead of a real account directory. Indeed, my prefs.js had:

<pre>
user_pref("mail.accountmanager.defaultaccount", "account4");
user_pref("mail.account.account4.server", "server4");
user_pref("mail.accountmanager.localfoldersserver", "server4");
user_pref("mail.server.server4.directory", "/existing/path/to/Local Folders");
</pre>

Note that "/existing/path/to/Local Folders" really exists!

By pointing "mail.accountmanager.defaultaccount" do another existing IMAP account spec I was able to solve the issue.

Thus, since there no choice about plain/HTML composition in *global* mail preferences, AND since the 'localfoldersserver' has no ID management options (or I'm blind), AND since composition pref is bound to an ID, as in

<pre>
user_pref("mail.identity.id1.compose_html", false);
</pre>

...then, I suspect that SM/TB blindly takes some hardcoded default oh HTML composition, which IMHO is Bad Thing (TM) ;-). In fact, resetting f.i. "mail.identity.id1.compose_html" to factory settings took back ID1 to HTML composition.
If this is confirmed, my very humble suggestion is to expose/implement a global pref key (set to 'false' by default, of course!)

<pre>
mail.compose.html
</pre>

and let each ID spec to override it.

HTH!

Cheers,

  ^m'e

Comment 12

[Mark Hammond [:markh] [:mhammond]]

Still in earlybird.  Haven't followed through with sphakka's comment #11, but none of my accounts default to html and I still have the problem.

One more "interesting" thing I found while making sure I can repro this:

1) Click "write" - new mail opened for editing; "from" correctly is from default account and plaintext editor opened.  Discard message.
2) Switch back to FF and click "mailto:" link - new mail opened for editing; "from" still correct but rich-text editor opened.

-- up until here we just have the bug as described above --

3) Discard message.  From TB, click "write" - new mail opened for editing; "from" correct but rich-text editor opened - but see (1) - I'd expect plaintext editor.
4) Repeat (3) - but new message is back to plaintext like (1)!

IOW, (3) happens exactly once after clicking the mailto: link - TB then reverts back to the expected behaviour.

Comment 13

[Andreas Glaeser]

This was filed as a Debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640306
It is not fixed yet in the current stable Version of T-bird 11.0.01
If someone could take care of fixing this bug, it would be highly appreciated, because in some cases the workaround of copying the mailto:-links from web-pages instead of clicking on them really does not produce identical results.
And please do consider to provide -.deb packages instead of tarballs, if possible.

Comment 15

[Jorg K (CEST = GMT+2)]

Does anyone still experience this bug in TB 60?

Comment 16

[Norbert]

(In reply to Jorg K (GMT+1) from comment #15)
> Does anyone still experience this bug in TB 60?

Yep.
But my problem is exactly the other way around.
I set up my mail account to always use HTML when composing new mail.
When hitting a mailto-Link in an incoming mail, a new composing window opens with just plain text.