Thunderbird autosave popup window shows incorrect buttons

[iGadget]

Binary package hint: mozilla-thunderbird

When using Mozilla Thunderbird on Hardy, an incorrect popup window is being displayed when saving or autosaving a draft message AND the message contains characters which are not in the selected Character Encoding.

See the attached screenshot.

When I click on one of the 'Send' buttons (tested with 'Send in UTF8'), the message is in fact saved, not sent.

So the word 'Send' in the buttons should be replaces by the word 'Save'. Or, when this dialog is the same as the one used when actually sending the message (which I doubt since the buttons actually do something else), a new dialog with the right buttons should be created.

[Mnyromyr (mnyromyr)]

(From update of attachment 294962)
Many thanks for taking this, Magnus!

[Mkmelin+mozilla (mkmelin+mozilla)]

Will also resolve at least bug 328938 and bug 311821.

[Rsx11m-pub (rsx11m-pub)]

> This patch gets rid of the "Send in UTF-8" dialog, and silently switches to
> utf-8 when necessary. It's protecting users from making unnecessary choices
> most of them not understand.

Agreed, that dialog is more confusing than helpful. My only concern is that the patch apparently does not honor the mailnews.reply_in_default_charset setting. Thus, if replying to a message that contains characters which cannot be encoded in the default character set, the presence of those characters would prompt the message to be sent in UTF-8 despite the user preference of always applying the selected default character encoding.

Maybe treat as "sendInUTF8" for mailnews.reply_in_default_charset=false but as "sendAnyway" if mailnews.reply_in_default_charset=true?

[Mkmelin+mozilla (mkmelin+mozilla)]

I don't see how that's related, this would only kick in if your reply contains characters the selected charset can't handle, the selected charset being set by the pref or not.

[Rsx11m-pub (rsx11m-pub)]

Unless I'm missing something, it should kick in if you are replying to a message which is in a different character encoding than your own default. Quoting that message, when it contains characters not representable in your default encoding, would prompt the upgrade to UTF-8, correct? In that case, the patch's behavior would override the user's preference to always reply in his or her own encoding. While for the reasons you mention it is questionable to send out a message with broken characters, that preference should be honored if set by the user.

[Mkmelin+mozilla (mkmelin+mozilla)]

(In reply to comment #5)
> Unless I'm missing something, it should kick in if you are replying to a
> message which is in a different character encoding than your own default.

Only if they can't coexist, so only for some cases. "Always reply in my default encoding" would instead become "always reply in my default encoding when possible", which I assume is what people expect. Why would anyone contentiously send broken messages (in 2008, when it's perfectly acceptable to assume utf-8 support)? There is no point supporting a pref just for the sake of it.

[Rsx11m-pub (rsx11m-pub)]

Ok, I see your point. My understanding was that this preference means to send the user's encoding "no matter what"; given your interpretation, it would simply mean to start off with the user's preferred encoding rather than the actual encoding of the message replied to, then move to UTF-8 if a character doesn't fit.

Concern resolved.

[Petr Hroudný (petr-hroudny)]

This bug is actually trying to avoid broken messages. If someone sets default charset to iso-8859-1, it would be unwise to enforce it ultimately and completely disallow e.g. latin-2 characters completely.

So yes, it should work as you describe - if reply_in_default_charset is set, Thunderbird should start off with your default charset (and not with the charset from original message). But if the text doesn't fit it should silently switch to UTF-8 like in all other cases without asking the users questions they don't understand and without giving them opportunity to break emails by clicking "Send anyway".

[Rsx11m-pub (rsx11m-pub)]

Thanks, makes perfectly sense now. I was reading that preference too literally.

[Daira Hopwood (daira)]

I agree with comment #6, but in that case the UI text for that pref should be
changed to "always reply in my default encoding when possible" (preferably in all localizations), rather than being left as it is.

[Mkmelin+mozilla (mkmelin+mozilla)]

David: any concerns with this, or is it just waiting in the sr queue?

[Bienvenu (bienvenu)]

(From update of attachment 294962)
no, I agree that killing this dialog would be a good thing, and is worth trying out.

[Mkmelin+mozilla (mkmelin+mozilla)]

Checking in mail/components/compose/content/MsgComposeCommands.js;
/cvsroot/mozilla/mail/components/compose/content/MsgComposeCommands.js,v <-- MsgComposeCommands.js
new revision: 1.127; previous revision: 1.126
done
Checking in mail/locales/en-US/chrome/messenger/messengercompose/composeMsgs.properties;
/cvsroot/mozilla/mail/locales/en-US/chrome/messenger/messengercompose/composeMsgs.properties,v <-- composeMsgs.properties
new revision: 1.17; previous revision: 1.16
done
Checking in mailnews/compose/resources/content/MsgComposeCommands.js;
/cvsroot/mozilla/mailnews/compose/resources/content/MsgComposeCommands.js,v <-- MsgComposeCommands.js
new revision: 1.413; previous revision: 1.412
done
Checking in mailnews/compose/src/nsComposeStrings.h;
/cvsroot/mozilla/mailnews/compose/src/nsComposeStrings.h,v <-- nsComposeStrings.h
new revision: 1.7; previous revision: 1.6
done
Checking in mailnews/compose/src/nsMsgCompose.cpp;
/cvsroot/mozilla/mailnews/compose/src/nsMsgCompose.cpp,v <-- nsMsgCompose.cpp
new revision: 1.558; previous revision: 1.557
done
Checking in mailnews/compose/src/nsMsgPrompts.cpp;
/cvsroot/mozilla/mailnews/compose/src/nsMsgPrompts.cpp,v <-- nsMsgPrompts.cpp
new revision: 1.32; previous revision: 1.31
done
Checking in mailnews/compose/src/nsMsgPrompts.h;
/cvsroot/mozilla/mailnews/compose/src/nsMsgPrompts.h,v <-- nsMsgPrompts.h
new revision: 1.9; previous revision: 1.8
done
Checking in mailnews/compose/src/nsMsgSend.cpp;
/cvsroot/mozilla/mailnews/compose/src/nsMsgSend.cpp,v <-- nsMsgSend.cpp
new revision: 1.419; previous revision: 1.418
done
Checking in mailnews/compose/src/nsMsgSendReport.cpp;
/cvsroot/mozilla/mailnews/compose/src/nsMsgSendReport.cpp,v <-- nsMsgSendReport.cpp
new revision: 1.17; previous revision: 1.16
done

[Mkmelin+mozilla (mkmelin+mozilla)]

Missed one file earlier.

Checking in suite/locales/en-US/chrome/mailnews/compose/composeMsgs.properties;
/cvsroot/mozilla/suite/locales/en-US/chrome/mailnews/compose/composeMsgs.properties,v <-- composeMsgs.properties
new revision: 1.90; previous revision: 1.89
done

[Mkmelin+mozilla (mkmelin+mozilla)]

Created an attachment (id=311842)
proposed fix (wording change for replyInDefaultCharset)

Change the wording for the mailnews.reply_in_default_charset.
The behaviour of *the pref* didn't really change, but now the charset is set to utf-8 as send time if need be.

Screen shots coming

[Mkmelin+mozilla (mkmelin+mozilla)]

Created an attachment (id=311844)
screenshot thunderbird

[Mkmelin+mozilla (mkmelin+mozilla)]

Created an attachment (id=311845)
screenshot seamonkey

[Neil-httl (neil-httl)]

(From update of attachment 311842)
>-<!ENTITY replyInDefaultCharset.label "Always use this default character encoding in replies. (When unchecked, only new messages use this default.)">
>-<!ENTITY replyInDefaultCharset.accesskey "w">
>+<!ENTITY replyInDefaultCharset2.label "When possible, use this default character encoding in replies. (When unchecked, only new messages use this default.)">
>+<!ENTITY replyInDefaultCharset2.accesskey "w">
Please change the access key to upper case to match the new text.

[Mkmelin+mozilla (mkmelin+mozilla)]

Checking in mailnews/base/prefs/resources/content/pref-character_encoding.xul;
/cvsroot/mozilla/mailnews/base/prefs/resources/content/pref-character_encoding.xul,v <-- pref-character_encoding.xul
new revision: 1.3; previous revision: 1.2
done
Checking in suite/locales/en-US/chrome/mailnews/pref/pref-character_encoding.dtd;
/cvsroot/mozilla/suite/locales/en-US/chrome/mailnews/pref/pref-character_encoding.dtd,v <-- pref-character_encoding.dtd
new revision: 1.3; previous revision: 1.2
done

Checking in mail/components/preferences/fonts.xul;
/cvsroot/mozilla/mail/components/preferences/fonts.xul,v <-- fonts.xul
new revision: 1.15; previous revision: 1.14
done
Checking in mail/locales/en-US/chrome/messenger/preferences/fonts.dtd;
/cvsroot/mozilla/mail/locales/en-US/chrome/messenger/preferences/fonts.dtd,v <-- fonts.dtd
new revision: 1.10; previous revision: 1.9
done

->FIXED

[Mnyromyr (mnyromyr)]

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

[Bugzilla-mozilla-org-rolf (bugzilla-mozilla-org-rolf)]

I generally agree with the approach taken here. But I want to discuss the following problem and see if we can accomodate it.

I am a German national that frequently writes mails to Japanese users. For some very strange reasons, the adoption of UTF-8 in Japan is still lacking to say the least. This patch will lead to a lot of mails that are unreadable on the other end. Not because the mail is incorrect, but because the recipient's software does not understand UTF-8. A lot of times this will be out of the recipient's control. Many Japanese receive mails on their mobile phone.

Can we maybe have a configurable list of encodings (try iso-8859-15 first, then iso-2022-jp, then default to utf-8)? any possible other ways to solve this?

[Mnyromyr (mnyromyr)]

(In reply to comment #21)
> This patch will lead to a lot of mails that are unreadable on
> the other end. Not because the mail is incorrect, but because the recipient's
> software does not understand UTF-8.

This patch only changes the last resort.

> Can we maybe have a configurable list of encodings (try iso-8859-15 first,
> then iso-2022-jp, then default to utf-8)? any possible other ways to solve
> this?

You already can, that's what the intl.fallbackCharsetList.* pref "family" is for. You can configure global encoding defaults in Mail&News -> Character Encoding, but we don't have a pref panel for configuring custom fallbacks.
In either case, please file new bugs for any problems/regressions with this one.

[Bugzilla-mozilla-org-rolf (bugzilla-mozilla-org-rolf)]

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

[Bugzilla-mozilla-org-rolf (bugzilla-mozilla-org-rolf)]

(In reply to comment #22)
> that's what the intl.fallbackCharsetList.* pref "family" is for.

I am using Thunderbird. And the above setting does not seem to change
anything. I opened bug 448842 about the regression issues wrt Japanese users
that this fix introduces.

[iGadget (igadget)]

Binary package hint: mozilla-thunderbird

When using Mozilla Thunderbird on Hardy, an incorrect popup window is being displayed when saving or autosaving a draft message AND the message contains characters which are not in the selected Character Encoding.

See the attached screenshot - the word 'Send' in the buttons should be replaces by the word 'Save'.

I haven't tested what actually happens when I click on one of the two 'Send' buttons, I will try this later.

[Joel Goguen (jgoguen)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Could you please confirm what version of Thunderbird you are running? You can check this from Thunderbird by going to the Help menu and choosing About Mozilla Thunderbird. Thanks in advance!

[iGadget (igadget)]

Joel, thanks for your reply. I was using the default most up-to-date version shipped with Hardy from the repo's.

Meanwhile, I've upgraded my installation to Intrepid (which ships wit 2.0.0.19). I will check if the problem exists there as well.

[iGadget (igadget)]

Confirmed - this bug is still present on Intrepid.

[Joel Goguen (jgoguen)]

Thank you for taking the time to confirm that this is still an issue. I have also been able to confirm this bug, just a few minutes before you posted that you had confirmed it. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

[Joel Goguen (jgoguen)]

This is solved by Mozilla 410333 (https://bugzilla.mozilla.org/show_bug.cgi?id=410333), which will not be moved back into the Thunderbird 2.x line. This bug should be marked Won't Fix.

[John Vivirito (gnomefreak)]

On 03/12/2009 10:01 PM, Joel Goguen wrote:
> This is solved by Mozilla 410333
> (https://bugzilla.mozilla.org/show_bug.cgi?id=410333), which will not be
> moved back into the Thunderbird 2.x line. This bug should be marked
> Won't Fix.
>
Thanks, Marked as invalid since it wont land in 2.0

 status invalid

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

[John Vivirito (gnomefreak)]

Changing to wont fix since this wont land in 2.0 but should land in 3.0

[iGadget (igadget)]

Thanks for all your replies. I have a question, though - what about Hardy, will Thunderbird 2 be upgraded to version 3 as well? It'd be a real shame if bugs such as these stay part of an LTS... I really can't explain this to my customers.

[John Vivirito (gnomefreak)]

On 03/13/2009 09:59 AM, Matthijs ten Kate wrote:
> Thanks for all your replies. I have a question, though - what about
> Hardy, will Thunderbird 2 be upgraded to version 3 as well? It'd be a
> real shame if bugs such as these stay part of an LTS... I really can't
> explain this to my customers.
>
Here is output from our IRC bot about the version in Hardy
> Version 2.0.0.19+nobinonly-0ubuntu0.8.04.1
Please make sure you have hardy-security repos enabled in
/etc/apt/sources.list

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

[iGadget (igadget)]

John, thanks for your reply. I'm fully aware of the current version Hardy, but that doesn't answer my question. Since you just mentioned this bug will not get fixed in the Thunderbird 2 branch, I'm wondering if a fix to this bug is ever going to land in Hardy (by shipping Thunderbird 3 to Hardy).

If not (perhaps due to a 'we-don't-ship-newer-versions-to-old-releases' policy), how am I going to explain to my customers this bug is not going to get fixed?

"Sorry, please upgrade to 10.04 when it ships... more than a year from now"?

[John Vivirito (gnomefreak)]

On 03/13/2009 11:28 AM, Matthijs ten Kate wrote:
> John, thanks for your reply. I'm fully aware of the current version
> Hardy, but that doesn't answer my question. Since you just mentioned
> this bug will not get fixed in the Thunderbird 2 branch, I'm wondering
> if a fix to this bug is ever going to land in Hardy (by shipping
> Thunderbird 3 to Hardy).
>
> If not (perhaps due to a 'we-don't-ship-newer-versions-to-old-releases'
> policy), how am I going to explain to my customers this bug is not going
> to get fixed?
>
> "Sorry, please upgrade to 10.04 when it ships... more than a year from
> now"?
>
I'm sorry, This is something we would need to think about long and hard
if we want to backport Thunderbird-3 to a LTS release. I an not saying
that we wont but this is something that can not be decided at this time
since Thunderbird-3.0 is not yet a stable release,

Until its stable and in official repos there is nothing we can do,You
can test Thunderbird-3.0 from the following repos(1).

I warn you this is not a repo you want to use in /etc/apt/sources.list
they are updated daily and not tested before hitting the PPA repos.
My suggestion is to just download the .deb files from the repo and see
if you can reproduce this problem.

Once it is in Jaunty+1 we are than able to decide what is best.
Introducing bugs into a LTS(2) is not acceptable, Adding 3.0 if stable
or not doesn't mean bugs wont be introduced. The comment just below as a
quote is the main objective of LTS

> These include security updates and corrections for
> other high-impact bugs, with a focus on maintaining stability and
> compatibility with Ubuntu 8.04 LTS.

I am sorry this post is so long but i wanted to be able to answer your
question as best as possible. Release after Jaunty will use the number
of 9.10. Best thing to do is either email the mozillateam mailing list(3)
Or ask in #ubuntu-mozillateam channel on IRC(4)

(1)
deb http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu jaunty main

(2)
https://lists.ubuntu.com/archives/ubuntu-announce/2009-January/000117.html

(3)
<email address hidden>

(4)
Server:
irc.freenode.net
Channel:
#ubuntu-mozillateam

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

[iGadget (igadget)]

John, thanks for your long reply, I appreciate it. I understand the dilemma of not wanting to introduce new bugs into an LTS.

However, I believe these kind of issues show a weakness in the whole LTS philosophy, because most code comes from external parties (in this case, Mozilla). When they say 'won't fix', it essentially means that the 'S' in LTS is becoming less valid.
Looking at it from an outsiders' perspective, I'd say "So what, it's open source, right? Canonical doesn't need Mozilla, they can fix it themselves." But in reality, this doesn't happen (perhaps for all the right reasons, but from a customer's perspective, it's just sub-optimal support).

If I'm awfully mistaken in this, please let me know. If not, perhaps this is something that should be addressed in general.

For now, thanks again for your extensive reply.

[John Vivirito (gnomefreak)]

On 03/16/2009 06:42 AM, Matthijs ten Kate wrote:
> John, thanks for your long reply, I appreciate it. I understand the
> dilemma of not wanting to introduce new bugs into an LTS.
>
> However, I believe these kind of issues show a weakness in the whole LTS philosophy, because most code comes from external parties (in this case, Mozilla). When they say 'won't fix', it essentially means that the 'S' in LTS is becoming less valid.
> Looking at it from an outsiders' perspective, I'd say "So what, it's open source, right? Canonical doesn't need Mozilla, they can fix it themselves." But in reality, this doesn't happen (perhaps for all the right reasons, but from a customer's perspective, it's just sub-optimal support).
>
> If I'm awfully mistaken in this, please let me know. If not, perhaps
> this is something that should be addressed in general.
>
> For now, thanks again for your extensive reply.
>
For more info on why we cant, please see:
https://wiki.ubuntu.com/StableReleaseUpdates
The link above is all about updates to stable versions of Ubuntu.
There is nothing in Ubuntu rules that allows us to do this and i wouldnt
do it anyway for updates.
As for backports we didnt back port firefox-2.0 to Dapper becuase of the
instablity risks that go along with it. I am against back porting this
to Hardy as well.
If you look at the back ports in prior releases you will notice no
Mozilla products due to the size and the bugs that it will introduce.
Its not worth the risk. Please join us on irc in the channel
#ubuntu-mozillateam to discuss this more.

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

[Gary-rumblingedge (gary-rumblingedge)]

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