508783 - Date.toLocaleFormat seems broken with some unicode characters

Status: RESOLVED DUPLICATE of bug 818634

(Core :: JavaScript Engine, defect)

Description

[Neil Roberts]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1) Gecko/20090624 Firefox/3.5

If I pass the string "\u4eca\u5929\u0025\u0048\u70b9\u0025\u004d\u5206" to Date.toLocaleFormat it throws an exception stating "An error occured throwing an exception".

The string is a normal time format containing some Chinese characters. It appears to work ok with some Chinese characters but that particular string makes it throw an exception.

I stepped through a short way with gdb and it appears that the call to js_GetStringBytes in date_toLocaleFormat is returning "\312)%H\271%M\006" which looks like garbage. At least it's not valid UTF-8 which is what I would expect. I am in a UTF-8 locale.

The call to strftime further on succeeds but then it fails when it tries to convert the string back to unicode.

Reproducible: Always

Steps to Reproduce:
Please visit the URL given for an example script exhbiting the problem.
Actual Results:  
The page displays two strings - the top one is the raw time format string and the second one is the result from calling toLocaleFormat with that string. The first string displays ok but the second string throws an exception instead.

Expected Results:  
The second string should be correctly formatted with the current time.

Comment 1

[Ian Stirling.]

3.5.2 - for me it's sort-of-working - and throws no exception.
I get the otuput "Ê)13¹51" - which is - sort-of- the current time.
Can you try 3.5.2 - it looks like the breakage changed.

Comment 2

[Neil Roberts]

I get exactly the same results in 3.5.2. I think it might depend on what locale you are using. Ian, are you using a UTF-8 locale?

It looks like it converts the string to a C string with js_GetBytes and then converts it back with localeCallbacks->localeToUnicode. In my case this would attempt to convert a UTF-8 string to UTF-16 because I am in a UTF-8 locale but it fails because the string is garbage.

js_GetBytes appears to just take the least significant byte of each unicode character which is why it is giving garbage. The documentation does say that it will corrupt strings. js_GetBytes is the wrong function to use in this case but there is no localeCallbacks->localeFromUnicode which I think is what we want.

Comment 3

[Wladimir Palant]

Confirming - just observed how this bug broke Adblock Plus on Windows Vista with Firefox 3.6. With Georgian date format selected in Windows control panel typing "javascript:alert(new Date().toLocaleFormat())" into location bar already causes the exception described here.

Comment 4

[Wladimir Palant]

Note that bug 541346 is probably a duplicate of this one.

Comment 5

[Wladimir Palant]

Also reproduced with Minefield build 20100310 on Windows 7 by changing system locale to Georgian.

Comment 6

[Simon Montagu :smontagu]

Is this the same as bug 441370?

Comment 7

[Wladimir Palant]

Why would you think that? Bug 441370 is about wrong locale being selected, in a context that doesn't have the correct callbacks. Here we get an exception, a non-English locale is selected (callbacks are set up correctly) and it is reproducible in the "usual" contexts.

Comment 8

[Brian Marshall]

Attachment: Example page demonstrating the bug

This bug can actually break all further use of Date.toLocaleFormat after it's triggered, even with date formats that wouldn't normally cause an exception. This problem persists until Firefox is restarted.

I'm attaching an example page that makes three calls to Date.toLocaleFormat to demonstrate this problem.

The first time the page is loaded, the first format is parsed perfectly. The second format contains some kanji, and produces a mangled date string, but doesn't throw an exception. The third format is identical to the first, but this time it throws an exception, because it's called after the second format with kanji.

The second time it's loaded (e.g., by reloading the page), all formats throw an exception. Now *every* call to Date.toLocaleFormat from anywhere in Firefox will throw an exception until Firefox is restarted.

This example is different from the URL provided in the bug in that the behavior changes the second time it's loaded.

Comment 9

[André Bargull [:anba]]

toLocaleFormat was removed in bug 818634.