tree fc709af32f5d7e1bd23b1779c524a48dd8afb46e
parent d2c99bacac294cc42147e4e312a615d843783ae6
author Dale Curtis <dalecurtis@chromium.org> 1558392832 +0000
committer Commit Bot <commit-bot@chromium.org> 1558392832 +0000

Remove kHaveFutureData restriction from play state notifications.

Take 2. This is a reland of b0ec93f6f1c9dd4754c813f198336a7a4c2f22a4,
where by all issues which caused its revert should be fixed now, so
lets give it another shot.

Now that we're looking to launch preload=metadata lazy load more
broadly, we need to remove this so we can remove the buffering state
lies that WebMediaPlayerImpl tells to progress playback state updates.

---- [ Original description ] ----
HTMLMediaElement should tell WebMediaPlayer about play state changes
as soon as the kHaveMetaData state is reached.

This will eventually allow us to delete a bunch of guessing-game type
code for idle suspension and instead rely on actually getting a play()
call from Blink to wake up when needed.

We can't stop WMPI from reaching the future data state quite yet though,
because it has implications on the delivery of 'canplay' and 'canplaythrough'
events that need to be part of a larger preload=metadata experiment. See old
discussion on this here:

https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Jul/0007.html

Note: This change exposed some bugs in how the ready state maximum is used
and the states at which a video frame is expected. These issues are fixed
in the HTMLVideoElement.

BUG=694855, 756897, 809998, 812423, 879406
TEST=All existing tests pass.

Change-Id: I6f47359a883db5cedd035f5a5a526e5761a2e4c8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1610526
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Auto-Submit: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#661515}