Ubuntu
thunderbird package

When using SCIM ANTHY, autosaving fails, and then get asked about sending in UTF-8

Bug #482496 reported by Eduard Carcole
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mozilla Thunderbird
Fix Released
Medium
Mozilla Thunderbird 3.0
thunderbird (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: thunderbird

Using Ubuntu 9.10 amd64 bits with default language English USA.
If try to write an e-mail in English, autosaving works properly.

If try to write an e-mail in Japanese, using SCIM 1.4.9 with ANTHY (9100h), when performing automatically autosaving, a window appears asking me to send or not the e-mail in UTF-8, without pressing the button "Send".

The autosaving fails, and only roman characters are saved.
Japanese characters do not appear in the saved draft.

Then I changed autosaving time to 20 minutes to avoid problems...
But this is not a proper solution.....

I hope somebody can help, since I live in Japan and I need to write in Japanese very often.

ProblemType: Bug
Architecture: amd64
Date: Sat Nov 14 13:22:14 2009
DistroRelease: Ubuntu 9.10
Package: mozilla-thunderbird (not installed)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: thunderbird
Uname: Linux 2.6.31-14-generic x86_64
XsessionErrors:
 (gnome-settings-daemon:1974): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (polkit-gnome-authentication-agent-1:2020): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (nautilus:2009): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (gnome-panel:1999): Gdk-WARNING **: /build/buildd/gtk+2.0-2.18.3/gdk/x11/gdkdrawable-x11.c:952 drawable is not a pixmap or window
 (synaptic:2115): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper: assertion `node != NULL' failed

See original description
Revision history for this message
In , Mnyromyr (mnyromyr) wrote :

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

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Will also resolve at least bug 328938 and bug 311821.

Revision history for this message
In , Rsx11m-pub (rsx11m-pub) wrote :

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

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

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.

Revision history for this message
In , Rsx11m-pub (rsx11m-pub) wrote :

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.

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

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

Revision history for this message
In , Rsx11m-pub (rsx11m-pub) wrote :

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.

Revision history for this message
In , Petr Hroudný (petr-hroudny) wrote :

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".

Revision history for this message
In , Rsx11m-pub (rsx11m-pub) wrote :

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

Revision history for this message
In , Daira Hopwood (daira) wrote :

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.

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

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

Revision history for this message
In , Bienvenu (bienvenu) wrote :

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

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

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

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

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

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

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

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Created an attachment (id=311844)
screenshot thunderbird

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

Created an attachment (id=311845)
screenshot seamonkey

Revision history for this message
In , Neil-httl (neil-httl) wrote :

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

Revision history for this message
In , Mkmelin+mozilla (mkmelin+mozilla) wrote :

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

Revision history for this message
In , Mnyromyr (mnyromyr) wrote :

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

Revision history for this message
In , Bugzilla-mozilla-org-rolf (bugzilla-mozilla-org-rolf) wrote :

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?

Revision history for this message
In , Mnyromyr (mnyromyr) wrote :

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

Revision history for this message
In , Bugzilla-mozilla-org-rolf (bugzilla-mozilla-org-rolf) wrote :

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

Revision history for this message
In , Bugzilla-mozilla-org-rolf (bugzilla-mozilla-org-rolf) wrote :

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

Revision history for this message
In , Gary-rumblingedge (gary-rumblingedge) wrote :

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

Revision history for this message
Eduard Carcole (ecarcole) wrote :

Binary package hint: thunderbird

Using Ubuntu 9.10 amd64 bits with default language English USA.
If try to write an e-mail in English, autosaving works properly.

If try to write an e-mail in Japanese, using SCIM 1.4.9 with ANTHY (9100h), when performing automatically autosaving, a window appears asking me to send or not the e-mail in UTF-8, without pressing the button "Send".

The autosaving fails, and only roman characters are saved.
Japanese characters do not appear in the saved draft.

Then I changed autosaving time to 20 minutes to avoid problems...
But this is not a proper solution.....

I hope somebody can help, since I live in Japan and I need to write in Japanese very often.

ProblemType: Bug
Architecture: amd64
Date: Sat Nov 14 13:22:14 2009
DistroRelease: Ubuntu 9.10
Package: mozilla-thunderbird (not installed)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: thunderbird
Uname: Linux 2.6.31-14-generic x86_64
XsessionErrors:
 (gnome-settings-daemon:1974): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (polkit-gnome-authentication-agent-1:2020): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (nautilus:2009): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (gnome-panel:1999): Gdk-WARNING **: /build/buildd/gtk+2.0-2.18.3/gdk/x11/gdkdrawable-x11.c:952 drawable is not a pixmap or window
 (synaptic:2115): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper: assertion `node != NULL' failed

Revision history for this message
Micah Gersten (micahg) wrote :

Thank you for reporting this to Ubuntu. This should already be fixed in Thunderbird 3. If you'd like, you can test Thunderbird 3 in our daily PPA: https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa

Please report any other bugs you may find.

Changed in thunderbird (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Changed in thunderbird:
milestone: none → 3.0
Bug Watch Updater (bug-watch-updater)
Changed in thunderbird:
status: Unknown → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (6.7 KiB)

This bug was fixed in the package thunderbird - 3.0+nobinonly-0ubuntu1

---------------
thunderbird (3.0+nobinonly-0ubuntu1) lucid; urgency=low

  * New Upstream Release 3.0 (THUNDERBIRD_3_0_RELEASE)
    - LP: #50902 - Thunderbird displays useless dialog
    - LP: #52667 - Thunderbird doesn't support RFC-2369
    - LP: #49033 - Doesn't recognize upper case extension (.JPG)
    - LP: #56465 - Per folder column widths
    - LP: #68456 - CTRL-Shift-K bound to 2 functions
    - LP: #79337 - Typo in Server Information for Add Account Wizard
    - LP: #1084 - No scroll on full headers list
    - LP: #62071 - Middle click on scrollbar pastes instead of jumping
    - LP: #119358 - Weak default authentication mode
    - LP: #120672 - No option to empty junk folder with right click
    - LP: #96566 - movemail doesn't work with default privs
    - LP: #122529 - Non-Thunderbird IMAP folders not visible to Thunderbird
    - LP: #241276 - Not able to paste image into thunderbird compose window
    - LP: #244635 - scrollboxes scroll to offset 0 when resized
    - LP: #259387 - "Edit Message as New" broken for eml messages
    - LP: #120281 - Editing a message from the drafts folder leaves line breaks
    - LP: #115484 - Dialogue boxes too large for 1024x768 resolution
    - LP: #320034 - Mail with self referencing headers breaks threading
    - LP: #160794 - shortcuts different in windows and linux
    - LP: #280987 - thunderbird keeps asking a password when working off-line
    - LP: #369150 - Thunderbird splits email addresses with non-ascii characters
                    and a comma in From: field
    - LP: #135066 - Thunderbird doesn't use Ubuntu icon theme
    - LP: #297301 - after authentication error the password is forgotten
    - LP: #487541 - thunderbird-bin crashed with SIGSEGV (AFS filesystem)
    - LP: #485224 - Thunderbird saves double attachment file name endings on
                    FAT32 and NTFS
    - LP: #482496 - When using SCIM ANTHY, autosaving fails, and then get asked
                    about sending in UTF-8

  [ Fabien Tassin <email address hidden> ]
  * Add build-depends on autoconf2.13, autotolls-dev, mozilla-devscripts
    libglib2.0-dev (>= 2.12), libstartup-notification0-dev, libbz2-dev,
    libpixman-1-dev, libdbus-1-dev (>= 1.0.0), libdbus-glib-1-dev (>= 0.60),
    libhal-dev (>= 0.5.8), libasound2-dev, libreadline5-dev | libreadline-dev,
    libkrb5-dev
  * Update build-depends minimums for libx11-dev (>= 2:1.0),
    libgtk2.0-dev (>= 2.12), zlib1g-dev (>= 1:1.2.3), libpng12-dev (>= 1.2.0),
    libjpeg62-dev (>= 6b), libcairo2-dev (>= 0.5.8), libgnome2-dev (>= 2.16),
    libgnomevfs2-dev (>= 1:2.16), libgnomeui-dev (>= 2.16),
    libnss3-dev (>= 3.12.0~1.9b3)
  * Bump standards version to 3.8.0
  * Replace ${Source-Version} by ${binary:Version} in control file
    - update debian/control
  * Bump requirement for system nspr to >= 4.8 since Mozilla bug 492464 landed
  * Bump requirement for system nss to >= 3.12.3 since Mozilla bug 485052 landed
  * Use in-source hunspell when hunspell 1.2 is not available
  * Add conditionnal support for --with-libxul-sdk controlled by
    $(USE_SYSTEM_XUL)
    - update debian/rules
  * Add p...

Read more...

Changed in thunderbird (Ubuntu):
status: Triaged → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in thunderbird:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.