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

commit 4563c7c2c70ab5f09a017cad834d995485f75ec0
Author: srirama.m <srirama.m@samsung.com>
Date: Tue Mar 15 10:28:19 2016

Refactor resource load and resource selection algorithms as per spec

In the current code the resource load and resource selection algorithms
were mixed and there are no explicit entry points. Added new functions
invokeLoadAlgorithm and invokeResourceSelectionAlgorithm to separate
them and partially updated the code to match the spec.

BUG=592396

Review URL: https://codereview.chromium.org/1522463003

Cr-Commit-Position: refs/heads/master@{#381203}

[modify] https://crrev.com/4563c7c2c70ab5f09a017cad834d995485f75ec0/third_party/WebKit/LayoutTests/fast/mediacapturefromelement/HTMLMediaElementCapture-creation.html
[modify] https://crrev.com/4563c7c2c70ab5f09a017cad834d995485f75ec0/third_party/WebKit/LayoutTests/imported/web-platform-tests/html/semantics/embedded-content/media-elements/loading-the-media-resource/load-removes-queued-error-event-expected.txt
[modify] https://crrev.com/4563c7c2c70ab5f09a017cad834d995485f75ec0/third_party/WebKit/LayoutTests/imported/web-platform-tests/html/semantics/embedded-content/media-elements/loading-the-media-resource/resource-selection-invoke-load-expected.txt
[add] https://crrev.com/4563c7c2c70ab5f09a017cad834d995485f75ec0/third_party/WebKit/LayoutTests/media/video-force-preload-none-to-metadata-on-load.html
[add] https://crrev.com/4563c7c2c70ab5f09a017cad834d995485f75ec0/third_party/WebKit/LayoutTests/media/video-force-preload-none-to-metadata-on-play.html
[modify] https://crrev.com/4563c7c2c70ab5f09a017cad834d995485f75ec0/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
[modify] https://crrev.com/4563c7c2c70ab5f09a017cad834d995485f75ec0/third_party/WebKit/Source/core/html/HTMLMediaElement.h
[modify] https://crrev.com/4563c7c2c70ab5f09a017cad834d995485f75ec0/third_party/WebKit/Source/core/testing/Internals.cpp
[modify] https://crrev.com/4563c7c2c70ab5f09a017cad834d995485f75ec0/third_party/WebKit/Source/core/testing/Internals.h
[modify] https://crrev.com/4563c7c2c70ab5f09a017cad834d995485f75ec0/third_party/WebKit/Source/core/testing/Internals.idl

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

Observably different behavior in  issue 587789  is still happening after the patch.

On this demo page[0], we expect to see the output of canvas drawing. However in current ToT, canvas redraw happens after play(), frame is captured and sent but never displayed since loadResource() is not completed yet [2]. 

A small change of replacing "m_loadTimer.startOneShot(0, BLINK_FROM_HERE);" with "loadTimerFired(&m_loadTimer);" on [1] addresses the issue. loadResource() happens before play(), frame is captured, sent and displayed [3]. 

I am not too familiar with HTMLMediaElement internals, so I am not what I am describing fits the spec. Is there any restrcitions on loadResource() and play() order?

[0] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3897
[1] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp&rcl=1458760914&l=616
[2] Logs ToT
HTMLMediaElement::invokeLoadAlgorithm(0x210d34f0b580)
HTMLMediaElement::cancelPendingEventsAndCallbacks(0x210d34f0b580)
HTMLMediaElement::setPlaybackRate(0x210d34f0b580, 1.000000)
HTMLMediaElement::invokeResourceSelectionAlgorithm(0x210d34f0b580)
HTMLMediaElement::setShouldDelayLoadEvent(0x210d34f0b580, true)
HTMLMediaElement::play(0x210d34f0b580)
HTMLMediaElement::playInternal(0x210d34f0b580)
HTMLMediaElement::invalidateCachedTime(0x210d34f0b580)
HTMLMediaElement::setIgnorePreloadNone(0x210d34f0b580)
HTMLMediaElement::updatePlayState(0x210d34f0b580) - shouldBePlaying = false, isPlaying = false
[1:1:0323/192829:VERBOSE3:canvas_capture_handler.cc(176)] CreateNewFrame
HTMLMediaElement::selectMediaResource(0x210d34f0b580)
HTMLMediaElement::loadResource(0x210d34f0b580, blob:http%3A//software.hixie.ch/dfac4367-536d-40e3-8c2b-e12bd997b68e, )
HTMLMediaElement::loadResource(0x210d34f0b580) - m_currentSrc -> blob:http%3A//software.hixie.ch/dfac4367-536d-40e3-8c2b-e12bd997b68e
HTMLMediaElement::setNetworkState(0x210d34f0b580, 2) - current state is 2
HTMLMediaElement::setReadyState(0x210d34f0b580, 0) - current state is 0,
HTMLMediaElement::selectMediaResource(0x210d34f0b580), using 'src' attribute url
HTMLMediaElement::stop(0x33ca53c37140)

[3] Logs after the change
HTMLMediaElement::invokeLoadAlgorithm(0x34e007acb580)
HTMLMediaElement::cancelPendingEventsAndCallbacks(0x34e007acb580)
HTMLMediaElement::setPlaybackRate(0x34e007acb580, 1.000000)
HTMLMediaElement::invokeResourceSelectionAlgorithm(0x34e007acb580)
HTMLMediaElement::setShouldDelayLoadEvent(0x34e007acb580, true)
HTMLMediaElement::selectMediaResource(0x34e007acb580)
HTMLMediaElement::loadResource(0x34e007acb580, blob:http%3A//software.hixie.ch/30d2175f-e83b-4ae3-99ad-4809a6e11cab, )
HTMLMediaElement::loadResource(0x34e007acb580) - m_currentSrc -> blob:http%3A//software.hixie.ch/30d2175f-e83b-4ae3-99ad-4809a6e11cab
HTMLMediaElement::setNetworkState(0x34e007acb580, 2) - current state is 2
HTMLMediaElement::setReadyState(0x34e007acb580, 0) - current state is 0,
HTMLMediaElement::selectMediaResource(0x34e007acb580), using 'src' attribute url
HTMLMediaElement::play(0x34e007acb580)
HTMLMediaElement::playInternal(0x34e007acb580)
HTMLMediaElement::invalidateCachedTime(0x34e007acb580)
HTMLMediaElement::setIgnorePreloadNone(0x34e007acb580)
HTMLMediaElement::updatePlayState(0x34e007acb580) - shouldBePlaying = false, isPlaying = false
[1:1:0323/192319:VERBOSE3:canvas_capture_handler.cc(176)] CreateNewFrame
HTMLMediaElement::setReadyState(0x34e007acb580, 1) - current state is 0,
HTMLMediaElement::addVideoTrack(0x34e007acb580, 'video', 'main', 'Video Track', '', 1)
HTMLMediaElement::updatePlayState(0x34e007acb580) - shouldBePlaying = false, isPlaying = false

Now that resource selection is never synchronous but happens after a startOneShot timer, it's to be expected that no frame ever reaches the media element. I assume that HTMLCanvasElement::notifyListenersCanvasChanged is now always called before HTMLMediaElement::loadResource, can you confirm?

After issue 593289 is fixed, I actually don't know what the behavior will be. Resource selection will then happen in a microtask, but https://github.com/w3c/mediacapture-fromelement/issues/29 and https://github.com/whatwg/html/issues/924 have to be fixed for the result to be well defined.

If it's resolved in a manner similar to https://github.com/whatwg/html/issues/924#issuecomment-200414657 I think it would mean that http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3897 should work reliably per spec, because the resource selection should be done at the next microtask checkpoint, which will be before we return to the event loop and the bits where junov@ suggests that the frame capture requests are serviced.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot