Bug 18333
Summary: | NPAPI: No way of telling the difference between 'ints' and 'doubles'. | ||
---|---|---|---|
Product: | WebKit | Reporter: | Jeremy Moskovich <playmobil> |
Component: | Plug-ins | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | ggaren, mjs |
Priority: | P2 | Keywords: | GoogleBug, NeedsReduction |
Version: | 528+ (Nightly build) | ||
Hardware: | Mac | ||
OS: | OS X 10.5 |
Jeremy Moskovich
Javascript technically only has a double datatype, however there is utility in telling the difference between the following two calls from JS into an NPAPI plugin:
plugin.method(42);
plugin.method(42.0);
In Mozilla, the former yields a variant for which NPVARIANT_IS_INT32() returns true, and for the latter NPVARIANT_IS_DOUBLE() returns true.
In WebKit there is no way to tell the difference (all numeric variants are reported as doubles).
A sample use case is an NPAPI plugin which needs to stringify numeric values, in this case there is no way of knowing whether a valid string representation would be '42' or '42.0'.
This bug affects Google Gears.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Eric Seidel (no email)
The values are long-converted to a double before the plugin code sees them. So I don't see how we'd implement this.
I'm not sure I understand the usecase. Why isn't handling the value as an int when it rounds to an int (within a certain delta) OK? I mean, I guess we could do that rounding for you...
http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/rendering/SVGRenderTreeAsText.cpp#L91
Is similar code to what I envision.
Jeremy Moskovich
The use case has to do with expected behavior when stringifying objects.
e.g. Create a DB table with a string column and insert the value 42.0 into it.
A user would expect the contents of the column to be '42.0', but if we round to an int ourselves we'll insert '42'.
So while you could argue that technically, WebKit behaves correctly. we have no way of implementing the behavior users expect in the above case. In addition, WebKit's handling of this case differs from that of Mozilla.
Darin Adler
I'm really surprised that Mozilla makes this distinction. It's definitely not called for by the JavaScript language. I'd be tempted to call this a bug in Mozilla rather than a bug in Safari.
There's no reason why we couldn't check for values that happen to fit in integers at the JavaScript bindings level and pass them as integers, but you still would not be able to distinguish 42 and 42.0.
Are you absolutely sure that Gecko's JavaScript engine allows you to tell the difference between 42 and 42.0? That is *very* surprising and really sounds like a bug to me.
Jeremy Moskovich
Agreed, please close the bug.
Maciej Stachowiak
Closed per originator's request.