Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification needed of behaviour when transferring animation callback IDs between different frame providers and cancelling invalid callbacks #5286

Closed
Cwiiis opened this issue Feb 13, 2020 · 2 comments

Comments

@Cwiiis
Copy link

Cwiiis commented Feb 13, 2020

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.

@domenic
Copy link
Member

domenic commented Feb 13, 2020

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 (let i = 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).

Again, no undefined behavior here. https://html.spec.whatwg.org/#animationframeprovider-cancelanimationframe step 3 (which links to https://infra.spec.whatwg.org/#map-remove) is very clear on what happens if the handle is not present in the map.

@Cwiiis
Copy link
Author

Cwiiis commented Feb 14, 2020

This sounds fair to me (and thanks for the clarification on the last point, I obviously missed that) - closing.

@Cwiiis Cwiiis closed this as completed Feb 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants