You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is in respect so section 8.11, 'Animation frames'.
The paragraph related to the callback id:
Each target object has a map of animation frame callbacks, which is an ordered map that must be initially empty, and an animation frame callback identifier, which is a number that must initially be zero.
It is also specified that the id is an unsigned long. As I interpret it, this means for each Document and each DedicatedWorkerGlobalScope, there is a map from unsigned long -> callback and that maps starts at zero and increases incrementally (I think there's scope to read it as returning any value as long as the first is zero and each value is unique, but that's besides the point here). This means that every AnimationFrameProvider is guaranteed to have at least one conflicting callback id at some point.
A question was raised as to what happens if you transfer the callback id and try to cancel it from a different context. As the id is just an unsigned long, there's nothing stopping the transfer(?) I assume this will result in essentially undefined behaviour - if there is a conflicting id, an unrelated callback will be cancelled, if there isn't, this will also result in undefined behaviour (there's nothing in the spec to say if there should be an error raised or not, and what type of error).
A clarifying paragraph would be good for this. Perhaps something along the lines of:
handle is only valid for the target object which returned it. Using it with a different target object will result in undefined behaviour, possibly cancelling an unrelated callback.
As for whether an error should be raised when trying to cancel a callback that doesn't exist, I suggest it shouldn't as it currently fails silently (at least in WebKit, but I assume that's the same in Chrome and likely Gecko). Introducing an exception here could well break existing sites. With that in mind, I suggest something along the lines of the following addendum to point 3 of cancelAnimationFrame.
If callbacks[handle] is not found, the method will return having done nothing.
The text was updated successfully, but these errors were encountered:
So, all of this is pretty well specified by the normative algorithms. There's definitely no undefined behavior!
Indeed, you can cancelAnimationFrame(anyArbitraryNumber); you can even do
for(leti=0;i<10000;++i){cancelAnimationFrame(i);}
There's no attempt to stop this, and there's certainly no attempt to stop this based on whether a given i also is used by some totally different AnimationFrameProvider.
if there isn't, this will also result in undefined behaviour (there's nothing in the spec to say if there should be an error raised or not, and what type of error).
This is in respect so section 8.11, 'Animation frames'.
The paragraph related to the callback id:
It is also specified that the id is an unsigned long. As I interpret it, this means for each Document and each DedicatedWorkerGlobalScope, there is a map from unsigned long -> callback and that maps starts at zero and increases incrementally (I think there's scope to read it as returning any value as long as the first is zero and each value is unique, but that's besides the point here). This means that every AnimationFrameProvider is guaranteed to have at least one conflicting callback id at some point.
A question was raised as to what happens if you transfer the callback id and try to cancel it from a different context. As the id is just an unsigned long, there's nothing stopping the transfer(?) I assume this will result in essentially undefined behaviour - if there is a conflicting id, an unrelated callback will be cancelled, if there isn't, this will also result in undefined behaviour (there's nothing in the spec to say if there should be an error raised or not, and what type of error).
A clarifying paragraph would be good for this. Perhaps something along the lines of:
As for whether an error should be raised when trying to cancel a callback that doesn't exist, I suggest it shouldn't as it currently fails silently (at least in WebKit, but I assume that's the same in Chrome and likely Gecko). Introducing an exception here could well break existing sites. With that in mind, I suggest something along the lines of the following addendum to point 3 of
cancelAnimationFrame
.The text was updated successfully, but these errors were encountered: