Date.toLocaleFormat seems broken with some unicode characters

RESOLVED DUPLICATE of bug 818634

Status

()

defect
RESOLVED DUPLICATE of bug 818634
10 years ago
2 years ago

People

(Reporter: neil, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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

10 years ago
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.
(Reporter)

Comment 2

10 years ago
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.

Updated

10 years ago
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 1.9.1 Branch

Comment 3

9 years ago
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.
Blocks: abp
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

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

Comment 5

9 years ago
Also reproduced with Minefield build 20100310 on Windows 7 by changing system locale to Georgian.
OS: Linux → All
Hardware: x86 → All
Version: 1.9.1 Branch → Trunk
Is this the same as bug 441370?

Comment 7

9 years ago
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.

Updated

9 years ago
No longer blocks: abp

Comment 8

9 years ago
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.
Assignee: general → nobody
toLocaleFormat was removed in bug 818634.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 818634
You need to log in before you can comment on or make changes to this bug.