Setting the media element currentTime property when its readyState is HAVE_NOTHING, returns early with no action.
According to the specification this should get/set an internal default playback position which should be used when the media is not in a ready state.
> 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.
The concept of "default playback position" has been around in the spec since October 2011 (https://web.archive.org/web/20111006043825/http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#default-playback-start-position), but the WebKit implementation isn't aware of it and just resorts to regular seeks in those cases.
Created attachment 436629 [details]
Comment on attachment 436629 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=436629&action=review
> + testExpected('video.currentTime', 2);
It would be useful to check the time after playback starts as well, to test the changes to `HTMLMediaElement::setReadyState`
> + }, 1500);
1500ms is probably short enough that we will have false-positives on a heavily loaded bot, so I'd use something much larger (6000?)
Created attachment 436774 [details]
Created attachment 436868 [details]
Created attachment 436902 [details]
Now only the Mac stress test bot fails.
CurrentTime "goes back" to 0 after the seeked event. I guess it's because we reset defaultPlaybackStartPosition (so the "actual" 0 position is now into effect for currentTime), but the seekTask() enqueued internally by seekWithTolerance() takes time to run, so that temporary 0 is visible. However, the "seeked" event is only triggered after the seek has been completed, so I don't know why the seek target time isn't returned.
Created attachment 437161 [details]
Committed r285571 (244079@main): <https://commits.webkit.org/244079@main>
All reviewed patches have been landed. Closing bug and clearing flags on attachment 437161 [details].