1.59 KB, message/rfc822
1.78 KB, message/rfc822
1.81 KB, patch
Jungshik Shin: review+
jag (Peter Annema): superreview+
|Details | Diff | Splinter Review|
6.32 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20060601 Firefox/22.214.171.124 (Ubuntu-edgy) Build Identifier: version 126.96.36.199 (20070306) I'm using mozilla thunderbird under kubuntu dapper drake 6.10. . My locale settings are as follows: LANG=hi_IN LC_CTYPE=hi_IN.UTF-8 LC_NUMERIC=hi_IN.UTF-8 LC_TIME=hi_IN.UTF-8 LC_COLLATE=hi_IN.UTF-8 LC_MONETARY=hi_IN.UTF-8 LC_MESSAGES=hi_IN.UTF-8 LC_PAPER=hi_IN.UTF-8 LC_NAME=hi_IN.UTF-8 LC_ADDRESS=hi_IN.UTF-8 LC_TELEPHONE=hi_IN.UTF-8 LC_MEASUREMENT=hi_IN.UTF-8 LC_IDENTIFICATION=hi_IN.UTF-8 LC_ALL= locales available on my machine are : bn_BD bn_IN C en_AU.utf8 en_BW.utf8 en_CA.utf8 en_DK.utf8 en_GB.utf8 en_HK.utf8 en_IE.utf8 en_IN en_IN.utf8 en_NZ.utf8 en_PH.utf8 en_SG.utf8 en_US.utf8 en_ZA.utf8 en_ZW.utf8 hi_IN hi_IN.utf8 POSIX Unless I change LC_TIME to en_US.UTF-8 some dates are not displayed by thunderbird, as the screenshot shows. Some dates are displayed properly, however. Reproducible: Always Steps to Reproduce: 1. 2. 3.
The screenshot is at http://191a.net/nodate.png . And I mistakenly stated that I'm using dapper drake when I actually meant edgy eft.
I believe the results should be reproducible on other machines by installing a hindi font (there should be an indic fonts package in your repository somewhere), exporting the variable and starting up your copy of thunderbird.
Could an extension cause the problem? Have you tried tb 2.0 (not final yet, but soon)? <http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/>
Magnus, Hi. Could you tell me how to run this particular file ? I downloaded the tarball and extracted it, but when I try and run thunderbird, I get the following error: karim@bhim:~/thunderbird-2.0pre.en-US.linux-i686/thunderbird$ pwd /home/karim/thunderbird-2.0pre.en-US.linux-i686/thunderbird karim@bhim:~/thunderbird-2.0pre.en-US.linux-i686/thunderbird$ ./thunderbird Segmentation fault karim@bhim:~/thunderbird-2.0pre.en-US.linux-i686/thunderbird$ Is this merely a problem with this particular nightly?
Since I couldn't get the nightly to run, I went home and built it on my Gentoo box. I was running tbird version 2 beta 2 build 20070316. I also disabled all extensions and made sure that LC_ALL and LC_CTIME were set to hi_IN.UTF-8 . The problem persisted and I have uploaded a flash video that illustrates the issue to http://191a.net/baddates.html .
On the unstable build (running on Gentoo), i get this message (I think it's not relevant but pasting anyway) Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIIOService2.manageOfflineStatus]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///usr/lib/mozilla-thunderbird/components/offlineStartup.js :: anonymous :: line 95" data: no] Source File: file:///usr/lib/mozilla-thunderbird/components/offlineStartup.js Line: 95
Created attachment 258942 [details] Email that does not display the date field. This is an email (.eml file) that does not display the date field.
Created attachment 258943 [details] Email that DOES display the date Thunderbird DOES show the date of this email (.eml file)
Is it possible that dates with times PM are being displayed and times AM are not?
More exactly, I think some dates need more space than the 80 bytes that we allow in nsDateTimeFormatUnix::FormatTMTime().
Created attachment 258982 [details] [diff] [review] Patch I think that this was probably the original intention, considering that NSDATETIME_FORMAT_BUFFER_LEN*2 is the size of strOut.
Comment on attachment 258982 [details] [diff] [review] Patch r=jshin It appears that 'x2' factor was used originally for the inflation of a single byte in ASCII/ISO-8859-x to 2 bytes. Probably because UTF-8 locales were not widely used.
Moving back to the original component to request blocking-thunderbird2. This makes the main mail display seriously hard to use and affects all the Indian languages. Risk is minimal: the patch doesn't even change the size of the buffer used to receive the formatted date string.
Comment on attachment 258982 [details] [diff] [review] Patch oops. forgot '+' it
Created attachment 259086 [details] [diff] [review] The not-so-quick fix This compiles (on my Mac) but is untested. Maybe something we should consider for trunk?
Comment on attachment 258982 [details] [diff] [review] Patch sr=jag for a minimalistic branch fix.
Comment on attachment 258982 [details] [diff] [review] Patch We could be tagging for Thunderbird 2 as early as tomorrow morning, I'll ping the 188.8.131.52 triage team to see if they'll approve this for the branch. It looks very low risk and fixes a problem for intl mail users on linux.
Comment on attachment 258982 [details] [diff] [review] Patch Approved for 1.8/1.8.0 branches, a=dveditz
Simon, I'll land the branch patch for 1.8 later tonight if you don't beat me to it to ensure that's its checked in before we tag tomorrow morning. Thanks again for working on this.
Simon I landed this on the 1.8 branch tonight so it would make it into tb2. I'll let you land it on the trunk and the 1.8.0 branch. Thanks again for the patch.
Comment on attachment 259086 [details] [diff] [review] The not-so-quick fix This has to be the most generous response to a sr request ever :) I wanted to do something like this for trunk after getting the quick fix in for TB2. Thanks for beating me to it.
Landed on 1.8.0 branch. Thanks for the 1.8 checkin, Scott.
It would be good to have a test for this, but do we have a way to force a locale when running tests?
Comment on attachment 259086 [details] [diff] [review] The not-so-quick fix The function here has a locale argument, doesn't it? But the system may not have the hi_IN locale installed, so testing this may not be possible... nsDateTimeFormatUnix.cpp + stringOut.AssignLiteral(""); I'd make that stringOut.Truncate(); + if (NS_SUCCEEDED(rv)) + stringOut.Assign(unichars, unicharLength); I think you could use stringOut.SetLength/BeginWriting to write directly to that string.
(In reply to comment #23) > Landed on 1.8.0 branch. Thanks for the 1.8 checkin, Scott. > I just upgraded to 184.108.40.206_rc1 and the problem still remains. Is the 1.8.0 branch not going to be used for thunderbird 220.127.116.11 ?
thunderbird 2 was shipped from 18.104.22.168. So this fix will show up in the first security update after the release. Sorry for the confusion.
jag, can you go ahead and check this in?