Make the currentTime setter clamp to duration

[foolip]

In https://github.com/web-platform-tests/wpt/pull/32832 @muan has reported an interop issue between browsers when setting video.currentTime to a value larger than video.duration. I haven't tested and verified today, but I believe Chrome and Firefox clamp it to the duration, while Safari returns back the set value. I'm not sure exactly when Safari clamps and starts returning the clamped value.

Safari matches the current spec as far as I can tell, because the currentTime setter updates the official playback positions and then seeks.

However, it seems like a relatively small change to the spec is possible that would allow browsers to align here.

The seeking algorithm already determines a new playback position synchronously, but it is not observable to script synchronously. We could set the official playback position in this algorithm, and not set it in the currentTime setter.

I have one doubt, which is that per the current spec, an implementation could arrange for currentTime to start returning the new value right before the seeking event is fired, guaranteeing that the change isn't seen before then. If Safari actually does that, then I think my proposal isn't as good.

cc @whatwg/media

[foolip]

@eric-carlson your feedback on the Safari behavior would be great here. (Also, long time no GitHub, hope you're doing well!)

[muan]

I have also brought this up to @eric-carlson in person at TPAC and got some clarification hence my follow-up comment in WPT. I think what you summarized here is essentially my takeaway. But interop issue remains so thank you @foolip for opening this!

[annevk]

We should also clarify what happens with negative values. Probably clamped to 0?

cc @jyavenard

[jyavenard]

The spec for seeking is quite explicit https://html.spec.whatwg.org/multipage/media.html#seeking

step 6 and step 7:

6- If the new playback position is later than the end of the media resource, then let it be the end of the media resource instead.
7- If the new playback position is less than the earliest possible position, let it be that position instead

and step 11:

11 -Set the current playback position to the new playback position.

As such clamping the currentTime immediately upon setting to be between 0 and duration is required.

[jyavenard]

The seeking algorithm already determines a new playback position synchronously, but it is not observable to script synchronously. We could set the official playback position in this algorithm, and not set it in the currentTime setter.

I have a different read to the spec that what you mention. In the synchronous step of the seeking algorithm it's the "current playback position" that you set, not a "new playback position"