Bug 314624 – time update event can be fired while we are seeking, before the seek completed

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Jean-Yves Avenard [:jya]]

Observed with the test imported/w3c/web-platform-tests/media-source/mediasource-duration.html 

The test seeks and expect the event to be in the order of "seeking" followed by "timeupdate"

However, there is the progress observer firing the timeupdate every 250ms ; it causes the test to intermittently fail prior the seeking event being dispatched if the timer fires while the seeking event is in flight.

The specs state:
"If the time was reached through the usual monotonic increase of the current playback position during normal playback, and if the user agent has not fired a timeupdate event at the element in the past 15 to 250ms and is not still running event handlers for such an event, then the user agent must queue a media element task given the media element to fire an event named timeupdate at the element. (In the other cases, such as explicit seeks, relevant events get fired as part of the overall process of changing the current playback position.)"

As such, it can be read that due to the explicit seek, the regular timeupdate shouldn't fire.

[Radar WebKit Bug Importer]

<rdar://problem/176861767>

[Jean-Yves Avenard [:jya]]

Pull request: https://github.com/WebKit/WebKit/pull/64758

[EWS]

Committed 313165@main (612b528ca587): <https://commits.webkit.org/313165@main>

Reviewed commits have been landed. Closing PR #64758 and removing active labels.