28125 2015-03-03 02:00:50 +0000 Pausing a playing media element requires the final paused position to be known synchronously 2016-02-01 17:26:16 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED MOVED https://html.spec.whatwg.org/#internal-pause-steps P3 normal Unsorted 1 contributor ian ian mike philipj contributor oldest_to_newest 118239 0 contributor 2015-03-03 02:00:50 +0000 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 118240 1 philipj 2015-03-03 02:10:06 +0000 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.) 118322 2 ian 2015-03-04 22:05:17 +0000 Will anything break if we make it async? 118349 3 philipj 2015-03-05 07:20:59 +0000 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. 124793 4 philipj 2016-02-01 17:26:16 +0000 Would be fixed as part of https://github.com/whatwg/html/issues/310