This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

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 ...
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: 2016-10-23 00:58 UTC (History)
6 users (show)

See Also:


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 (Not reading bugmail) 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...
Comment 5 Domenic Denicola 2016-10-22 15:56:23 UTC
In we made the infinity/NaN handling for canvas methods unambiguous and explicit in HTML, with Boris's participation. Given that we don't want to do this kind of handling again, I don't think this is necessary anymore. Boris, please reopen if you disagree.
Comment 6 Boris Zbarsky 2016-10-23 00:58:06 UTC
That seems fine, since we changed from using action-at-a-distance prose to prose in the relevant methods.

Gecko will continue using [LenientFloat] in its IDL to save on mental overhead, but I changed its behavior to be black-box indentical to the new prose in HTML.