WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
224363
When seeking past the duration, currentTime will return the unadjusted seek time.
https://bugs.webkit.org/show_bug.cgi?id=224363
Summary
When seeking past the duration, currentTime will return the unadjusted seek t...
Jean-Yves Avenard [:jya]
Reported
2021-04-09 02:12:26 PDT
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.
Attachments
Patch
(8.65 KB, patch)
2021-04-09 07:53 PDT
,
Jean-Yves Avenard [:jya]
no flags
Details
Formatted Diff
Diff
Patch
(8.68 KB, patch)
2021-04-11 17:20 PDT
,
Jean-Yves Avenard [:jya]
no flags
Details
Formatted Diff
Diff
Patch
(8.69 KB, patch)
2021-04-11 17:33 PDT
,
Jean-Yves Avenard [:jya]
ews-feeder
: commit-queue-
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2021-04-09 02:13:04 PDT
<
rdar://problem/76444204
>
Jean-Yves Avenard [:jya]
Comment 2
2021-04-09 02:13:35 PDT
To add, both Firefox and Chromium based browsers will do as expected.
Jean-Yves Avenard [:jya]
Comment 3
2021-04-09 07:53:28 PDT
Created
attachment 425617
[details]
Patch
Jean-Yves Avenard [:jya]
Comment 4
2021-04-11 17:20:11 PDT
Created
attachment 425716
[details]
Patch
Jean-Yves Avenard [:jya]
Comment 5
2021-04-11 17:33:58 PDT
Created
attachment 425717
[details]
Patch
Jean-Yves Avenard [:jya]
Comment 6
2021-04-11 18:30:12 PDT
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]
Comment 7
2021-04-11 18:43:56 PDT
I opened
https://bugzilla.mozilla.org/show_bug.cgi?id=1704413
Jean-Yves Avenard [:jya]
Comment 8
2021-04-11 19:55:55 PDT
I opened
https://github.com/web-platform-tests/wpt/issues/28437
against the web-platform-test that checked this behaviour.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug