19988 2012-11-16 23:27:51 +0000 add a [LenientFloat] to mean "ignore IDL attribute assignment or method call if a non-finite float is passed" 2016-10-23 00:58:06 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified PC Windows 3.1 RESOLVED WONTFIX [v1] P2 normal --- 1 cam cam bzbarsky d jonas me mike public-script-coord public-webapps-bugzilla oldest_to_newest 78429 0 cam 2012-11-16 23:27:51 +0000 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. 78853 1 bzbarsky 2012-11-26 20:04:24 +0000 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. 78856 2 jonas 2012-11-26 20:14:38 +0000 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 78861 3 bzbarsky 2012-11-26 20:38:37 +0000 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.... 78885 4 bzbarsky 2012-11-27 01:39:30 +0000 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... 127918 5 d 2016-10-22 15:56:23 +0000 In https://github.com/whatwg/html/pull/1790 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. 127935 6 bzbarsky 2016-10-23 00:58:06 +0000 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.