This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: https://html.spec.whatwg.org/ Multipage: https://html.spec.whatwg.org/multipage/#internal-pause-steps Complete: https://html.spec.whatwg.org/#internal-pause-steps Referrer: Comment: Pausing a playing media element requires the final paused position to be known synchronously Posted from: 14.162.102.1 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36 OPR/27.0.1689.76
The internal pause steps say "Set the official playback position to the current playback position" as a synchronous part of those steps. The current playback position amounts to the time currently reported by the media framework, but if we are playing we still have to ask it to pause and wait for it to pause before known the final paused position. Blink actually implements this, but it causes a problem: https://code.google.com/p/chromium/issues/detail?id=460904 Because the media framework continues to play for a fraction of a second, the buffered ranges may change so that when paused, the official playback position is outside of the buffered ranges. This could be fixed by making pause() async similarly to seeking, which says "Wait until the user agent has established whether or not the media data for the new playback position is available, and, if it is, until it has decoded enough data to play back that position." (It could also be fixed by treating all state as a single data structure and always updating it together so that it cannot be inconsistent, but then it would still be stale after pausing.)
Will anything break if we make it async?
I'm pretty optimistic that it'd be Web compatible. For it to break, you need to use currentTime at the time you pause() and somehow depend on it being exactly unchanged when the pause event fires or something similar. It could be lack of imagination, but I'm failing to come up with a realistic scenario for this. As long as the timeupdate event is fired when the playback position has settled, any UI code that has the same bug found in Chromium (assuming that currentTime is in one of the buffered ranges) should start working.
Would be fixed as part of https://github.com/whatwg/html/issues/310