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:18.104.22.168) 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
Was this the case already in 2.x ?
Component: General → Message Compose Window
QA Contact: general → message-compose
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?
Happens on my machines too (desktop & laptop). Very annoying. Runningf WIndows XP Home.
I can confirm as well on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:22.214.171.124) Gecko/20100317 Thunderbird/3.0.4 and Thunderbird/3.1.3.
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.
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.
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:126.96.36.199) 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.
Confirmed in TB3.1.10 (windows;u;NT5.1;en-Us;rv:188.8.131.52) Gecko/20110414 in combination with FF 4.0.1 / Win7 64 Bit Still there and annoying
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) 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.
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.
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
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Does anyone still experience this bug in TB 60?
You need to log in before you can comment on or make changes to this bug.