Bug 19988 - add a [LenientFloat] to mean "ignore IDL attribute assignment or method call if a non-finite float is passed"
Summary: add a [LenientFloat] to mean "ignore IDL attribute assignment or method call ...
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC Windows 3.1
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
Whiteboard: [v1]
Depends on:
Reported: 2012-11-16 23:27 UTC by Cameron McCormack
Modified: 2013-06-17 01:22 UTC (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Cameron McCormack 2012-11-16 23:27:51 UTC
It sucks a bit that the various canvas APIs have to take "unrestricted float" and explicitly do nothing when non-finite Number values are passed/assigned to them.  We could add a [LeninentFloat] extended attribute that can be put on IDL operations that return void and have one or more float arguments (or union types that have a float in them) and writable IDL attributes of type float, which would mean that when converting the value to the IDL float, NaNs and infinities cause the invocation to return and do nothing rather than throwing.
Comment 1 Boris Zbarsky 2012-11-26 20:04:24 UTC
What I implemented in Gecko is that a type "contains restricted floats" if any of the following conditions hold:

1)  It is "float" or "double".
2)  It is a nullable type where the underlying type contains restricted floats.
3)  It's a union type where one of the union members contains restricted floats.
4)  It's a sequence type where the element type contains restricted floats.

and allowed [LenientFloat] on operations that return void and have an argument hat contains restricted floats or on writable attributes whose type contains restricted floats.
Comment 2 Jonas Sicking 2012-11-26 20:14:38 UTC
I'm really not sure that this needs to go into the WebIDL spec. It seems to me that using prose is a quite acceptable solution in this case.

What we do internally in Gecko can be something completely different of course as long as the behavior matches that of the IDL+prose
Comment 3 Boris Zbarsky 2012-11-26 20:38:37 UTC
Using prose is actually a terrible solution for this in practice.  When implementing a canvas method right now, you have to end up looking at three completely different places (the IDL, the prose for the method, and a second prose location that's in a totally different place and says that all methods that don't say otherwise have a certain behavior) to figure out what the behavior should be.  And when speccing a canvas method you have to be aware of this bit of action-at-a-distance prose....
Comment 4 Boris Zbarsky 2012-11-27 01:39:30 UTC
One other note.  There is an observable difference between the spec as written right now and what Gecko is doing with [LenientFloat].  In particular, consider this testcase:

  ctx.moveTo(NaN, { valueOf: { throw "HAHA"; } });

In Gecko's current implementation, and in the obvious way of defining [LenientFloat], this call will be a no-op.  Per spec as written right now, this call will throw, because the check for NaN on the first argument is done after converting all the arguments.

I could probably change Gecko to do the thing current prose says to do in this sort of edge case, but that would make it harder to optimize calls to such methods from the JIT...