WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
18333
NPAPI: No way of telling the difference between 'ints' and 'doubles'.
https://bugs.webkit.org/show_bug.cgi?id=18333
Summary
NPAPI: No way of telling the difference between 'ints' and 'doubles'.
Jeremy Moskovich
Reported
2008-04-06 12:09:35 PDT
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)
Comment 1
2008-04-07 08:03:05 PDT
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
Comment 2
2008-04-07 08:13:10 PDT
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
Comment 3
2008-04-16 07:33:54 PDT
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
Comment 4
2008-04-16 15:15:22 PDT
Agreed, please close the bug.
Maciej Stachowiak
Comment 5
2008-04-16 18:02:55 PDT
Closed per originator's request.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug