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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon May 12 12:09:19 PDT 2008


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





------- Comment #6 from digulla at hepe.com  2008-05-12 12:09 PDT -------
I couldn't find anything :/ I doubt that glibc offers this after finally
offering automatic locale specific formatting.

Why does the parseDouble() function expect "." even when the locale specifies
","?

Also, I wonder what a fix in String::format() would break. Will it work for
JavaScript, too? Like:

var x = 1.5;
var s = "" + x;
assert "1.5" == s;

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.

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.

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?

Argh... a Pandora Bug!

If everyone was using String::number(double) to format double values, we could
replace "," by "." in there. But that isn't very safe as long as
String::format() is not private (someone might try to format double values
manually, for example in a more complex format string).

The GNU header file locale.h mentions that there is some proof of concept code
to allow per-thread locales. But I'm not sure how fast this is (i.e. getting
the current locale, replace it with C, set it back after the double value has
been formatted).

*sigh* It would be easier if style.opacity would simply return a double value
:)

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?


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



More information about the webkit-unassigned mailing list