Thanks for these test cases! However, I'm seeing the opposite behavior, the "immediately" case doesn't play and the "after timeout" one does. Firefox Nightly does the same. Did you paste the wrong thing in the description, or is that the behavior you're seeing?

I added some console.log'ing of networkState, readyState and paused at the various steps to investigate.

Per spec, calling play() should invoke the "resource selection algorithm" if networkState == NETWORK_EMPTY, which is going to be the case here. That immediately sets networkState to NETWORK_NO_SOURCE and should "await a stable state" before looking at the src attribute. What the implementation actually does is to set a timer, which is equivalent to posting a task rather than a microtask. That's suspect, but doesn't seem to be to blame here.

Also per spec, setting the src attribute is supposed to invoke the "media element load algorithm", which resets the paused state, but ONLY if networkState != NETWORK_EMPTY. The implementation doesn't quite do this, but the relevant bits in HTMLMediaElement::prepareForLoad() are run with the correct timing. (The continuation is wrong, see issue 592396.)

So, what should happen is that in the "immediately" case, networkState is NETWORK_NO_SOURCE when the src attribute is called, so the paused attribute is reset. In the "after timeout" case the resource selection algorithm will already have run and failed to find a source an returned to NETWORK_EMPTY. That's why setting the src doesn't reset the paused state.

Even though per spec, this is somewhat confusing. You should always get reliable behavior by calling play() after setting the src.

I'm wondering if maybe the spec should change to always reset the paused state, but that would mean that calling play() before setting src never works, instead of sometimes working. Would that be an improvement?

You are correct, the first version does not play but the second does. It looks like I also switched the log names, which may have actually been the original source of confusion.

While it makes far more sense to set src and then call play(), the fact that some of the Chromium browser_tests are relying on the opposite is not a good sign for the compatibility of a change.

I've filed https://github.com/whatwg/html/issues/869, will close this as WontFix until there's a spec change. I couldn't find your GitHub account, can you add yourself if you're interested?

You're right that changing this behavior has some risk, I guess we'll have to add use counters if want to try it.

Renaming Blink>Video to Blink>Media>Video for better characterization

Reopening this because I'm looking into the issue. I can't actually get the video to play after setting the src. Are you all still able to reproduce this?

I can still reproduce this exactly on 54.0.2810.2, (noting that the descriptions in the first post are swapped. (It's the second one that plays and the first one that fails.)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e2c683031c305abcb6dab162832f95fa9b71545e

commit e2c683031c305abcb6dab162832f95fa9b71545e
Author: mlamouri <mlamouri@chromium.org>
Date: Thu Aug 04 15:32:36 2016

Change play promises behaviour in the load algorithm.

This is implementing the changes from the following whatwg/html PR:
https://github.com/whatwg/html/pull/1621

BUG= 592158 , 630622 
R=foolip@chromium.org

Review-Url: https://codereview.chromium.org/2199363002
Cr-Commit-Position: refs/heads/master@{#409793}

[modify] https://crrev.com/e2c683031c305abcb6dab162832f95fa9b71545e/third_party/WebKit/LayoutTests/media/media-play-promise.html
[modify] https://crrev.com/e2c683031c305abcb6dab162832f95fa9b71545e/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp