When seeking past the duration, currentTime will return the unadjusted seek time.

[Jean-Yves Avenard [:jya]]

Say you are playing a 10s video.

If you do:
video.currentTime = video.duration + 10;
testExpected(video.currentTime, video.duration);
await once(video, "seeked");
testExpected(video.currentTime, video.duration);

However, WebKit will return video.duration + 10 before the seeked event is fired.

However, per spec:

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

is done after step
"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."

While it could be arguable that the currentTime being set in the parallel task following step "If the seek was in response to a DOM method call or setting of an IDL attribute, then continue the script. The remainder of these steps must be run in parallel. With the exception of the steps marked with ⌛, they could be aborted at any time by another instance of this algorithm being invoked." (https://html.spec.whatwg.org/multipage/media.html#seeking)

However, per spec:
"11. Set the current playback position to the new playback position"

is done after step
"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."

So currentTime after the seek operation must return the clamped seek time to duration.

[Radar WebKit Bug Importer]

<rdar://problem/76444204>

[Jean-Yves Avenard [:jya]]

To add, both Firefox and Chromium based browsers will do as expected.

[Jean-Yves Avenard [:jya]]

Created attachment 425617 [details]
Patch

[Jean-Yves Avenard [:jya]]

Created attachment 425716 [details]
Patch

[Jean-Yves Avenard [:jya]]

Created attachment 425717 [details]
Patch

[Jean-Yves Avenard [:jya]]

Ok.

Upon more considerations, Safari's behaviour is correct.

When setting the currentTime attribute, we can read:
```
The currentTime attribute must, on getting, return the media element’s default playback start position, unless that is zero, in which case it must return the element’s official playback position. The returned value must be expressed in seconds. On setting, if the media element’s readyState is HAVE_NOTHING, then it must set the media element’s default playback start position to the new value; otherwise, it must set the official playback position to the new value and then seek to the new value. The new value must be interpreted as being in seconds.
```
[1]

But during seeking, step 11:
```
Set the current playback position to the new playback position.```
[2]

So it's the current playback position that can be set asynchronously (or as in the new language: "in parallel")
the official playback position is to be set:
```
Any time the user agent provides a stable state, the official playback position must be set to the current playback position.
```

So step 11 must not immediately change the official playback position.

[1] https://html.spec.whatwg.org/multipage/media.html#dom-media-currenttime
[2] https://html.spec.whatwg.org/multipage/media.html#seeking

[Jean-Yves Avenard [:jya]]

I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1704413

[Jean-Yves Avenard [:jya]]

I opened https://github.com/web-platform-tests/wpt/issues/28437 against the web-platform-test that checked this behaviour.