[Webkit-unassigned] [Bug 18994] LANG/LC_ALL influences the result of element.style.opacity

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=18994


ap at webkit.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alp at nuanti.com,
                   |                            |hausmann at webkit.org,
                   |                            |kevino at theolliviers.com




------- Comment #7 from ap at webkit.org  2008-05-12 12:54 PDT -------
(In reply to comment #6)
> Why does the parseDouble() function expect "." even when the locale specifies
> ","?

Well, a script downloaded from the Web can always pass a double as a literal
string, so we should worry about that case, too, not just round-tripping. User
locale should have no effect on scripts, except for methods that are
specifically documented as locale-sensitive.

> Also, I wonder what a fix in String::format() would break. 

On Mac OS X, locale does not affect printf/scanf by default, so such a fix is
unlikely to cause any problems.

> Will it work for JavaScript, too?

No, Platform::String is not used in JavaScriptCore. I am not aware of similar
bugs remaining in JavaScriptCore (although there used to be some, see bug
16162).

> My next idea was to set LANG/LC_ALL in the startup script but that would break
> if someone would embed WebKit in an application.

Precisely.

> Or we could patch the field "decimal_point" in "struct lconv". But that might
> introduce even more hideous bugs during embedding, especially when threads are
> used.

Ugh, I was assuming that locale was per-thread on Linux, and thought of this as
the most promising approach.

> Which leads to another question: Might the web developer want to *show* float
> values to the user? In this case, which locale should be used to format them?
> C? The locale of the page? The locale in which the browser runs?

ECMAScript-262 talks about "host environment's current locale" (see e.g.
15.5.4.9), which is what JavaScriptCore does. Other specifications have
different approaches, which are not always explicitly spelled out and which we
don't always fully implement yet. But let's keep discussion in this bug focused
on the specific issue at hand!

> I'll keep my eyes open for a solution for this but half an hour on Google
> didn't turn anything really useful up. Maybe ask the glibc maintainers for
> help?

Sounds like a good idea. I would also expect that Qt/gtk/wx have their
solutions for this issue, which we could potentially use.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.