Tested the issue on chrome Stable #54.0.2840.71, Canary 56.0.2899.0 in MAC 10.12 and was able to reproduce the issue.

This is a Non-Regression issue since seeing this from M35 #35.0.1898.0, Making the status to Untriaged so that the issue would get addressed.

Note : Able to reproduce the issue in Windows 10.0 and Linux Ubuntu 14.04.

Thank you.

In my environment, the image doesn't appear even on subsequent loads.

The image appears when I reload the page with devtools open (even on the initial load). me@sampotts.me, Is that what you are seeing?

I suspect the failure is probably being cached as well then maybe? Does Chrome cache the headers as well? I'm not sure. For me it works on subsequent loads but I usually have dev tools open. I run https://plyr.io and often get people saying the poster image is blank. 

I found a simpler reproduction. It's not related to video.

My understanding is Chrome is working as intended, and web developers need to do one of the followings:

 1. Add 'Access-Control-Allow-Origin: *' to every response
 2. Add 'Vary: Origin' to every response
 3. Specify 'Cache-Control: no-cache' on every response

Deleted: image.html 198 bytes

image.html 198 bytes View Download

I've found this happens on every machine I've tested on. It works correctly *after* the initial load as stated. You will see that the responses that work contain the correct headers and the image loads. Other browsers work fine. Chrome has a bug where with a fresh cache, the first hit does not send the CORS header in the request. As the first commenter said, this has been like this for a while. I've even changed CDNs from Cloudfront to Fastly to fix this issue but no luck. 

As far as I'm aware Vary: Origin is only required when whitelisting origins. Not sure "Cache-Control: no-cache" is required for CORS either as that would mean no CORS request could be cached? 

I'm 99.999% there's a bug here with Chrome. 

Let me know if you need more info. 

Checking again I'm not 100% sure it's cache related. It seems you might have to wait a period of time for the image to fail to load rather than it being cache based. 

(Talking at https://github.com/whatwg/fetch/issues/402)

Please see the discussion on GitHub.

So you're leaving this as broken? I could understand the if the image *never* loaded or *always* loaded but it *sometimes* loads. If you visit the page, it *might* load the poster image, it might not. If you refresh it definitely will. If you don't re-visit the page for a few days and then visit it again, chances are it *won't* load the poster image. 

E.g. if you've not visited plyr.io recently, open that and there's a high chance the post image *won't* load. 

It's a bug. As the first replier pointed out. It's been around for a while. 

Case and point:
https://www.dropbox.com/s/fbtcfibhstveqx2/Screenshot%202016-11-01%2023.37.08.png?dl=0

I fear it's an issue with cache. Notice I don't have disable cache checked and think that it's trying to use the cached resource as I have set 'cache-control:max-age=31536000' on the image. 

Here's a screen capture showing the behaviour:
http://recordit.co/cmorqmmdav

I initially have disable cache unchecked, refresh, then the image doesn't load, then check the checkbox, refresh and the image loads. 

To me, it's a bug. 

https://cdn.selz.com/plyr/1.5/View_From_A_Blue_Moon_Trailer-HD.jpg is requested twice (one with Origin header and another without Origin header), but I noticed I didn't know why Chrome does so. Reopening, and adding Blink>Media>Video.

It may effect the test results but I've adding the 'Vary: Origin` header to the image to see if that is the issue.  

Hmm.

The image 'https://cdn.selz.com/plyr/1.5/View_From_A_Blue_Moon_Trailer-HD.jpg' is requested three times.

1. No-cors request by preloader:
#2 0x000009c01723 blink::ResourceFetcher::requestResource()
#3 0x000009bb1b4e blink::ImageResource::fetch()
#4 0x00000ab1d675 blink::DocumentLoader::startPreload()
#5 0x00000a1a57f7 blink::HTMLResourcePreloader::preload()
#6 0x00000a2770fe blink::ResourcePreloader::takeAndPreload()
#7 0x00000a164218 blink::HTMLDocumentParser::fetchQueuedPreloads()
#8 0x00000a170751 blink::HTMLDocumentParser::documentElementAvailable()
#9 0x000009ed9e31 blink::HTMLHtmlElement::insertedByParser()
#10 0x00000a204217 blink::HTMLTreeBuilder::processStartTag()
#11 0x00000a1fd72c blink::HTMLTreeBuilder::constructTree()
#12 0x00000a162944 blink::HTMLDocumentParser::processTokenizedChunkFromBackgroundParser()
#13 0x00000a15b30e blink::HTMLDocumentParser::pumpPendingSpeculations()
#14 0x00000e6a81f5 blink::CancellableTaskFactory::CancellableTask::run()

2. CORS request in HTMLVideoElement::parseAttribute():
#2 0x000009c01723 blink::ResourceFetcher::requestResource()
#3 0x000009bb1b4e blink::ImageResource::fetch()
#4 0x00000ab83dfa blink::ImageLoader::doUpdateFromElement()
#5 0x00000ab852e5 blink::ImageLoader::updateFromElement()
#6 0x00000a046150 blink::HTMLVideoElement::parseAttribute()
#7 0x0000095ffb6d blink::Element::attributeChanged()
#8 0x000009603fd2 blink::Element::parserSetAttributes()
#9 0x00000a2508d6 blink::HTMLConstructionSite::createHTMLElement()
#10 0x00000a251306 blink::HTMLConstructionSite::insertHTMLElement()
#11 0x00000a20eb20 blink::HTMLTreeBuilder::processStartTagForInBody()
#12 0x00000a20323b blink::HTMLTreeBuilder::processStartTag()
#13 0x00000a1fd72c blink::HTMLTreeBuilder::constructTree()
#14 0x00000a162944 blink::HTMLDocumentParser::processTokenizedChunkFromBackgroundParser()
#15 0x00000a15b30e blink::HTMLDocumentParser::pumpPendingSpeculations()
#16 0x00000e6a81f5 blink::CancellableTaskFactory::CancellableTask::run()

3. CORS request in HTMLVideoElement::attachLayoutTree():
#2 0x000009c01723 blink::ResourceFetcher::requestResource()
#3 0x000009bb1b4e blink::ImageResource::fetch()
#4 0x00000ab83dfa blink::ImageLoader::doUpdateFromElement()
#5 0x00000ab852e5 blink::ImageLoader::updateFromElement()
#6 0x00000a0457d5 blink::HTMLVideoElement::attachLayoutTree()
#7 0x0000094c7541 blink::ContainerNode::attachLayoutTree()
#8 0x000009607a7d blink::Element::attachLayoutTree()
#9 0x0000096de601 blink::Node::reattachLayoutTree()
#10 0x00000960d9ac blink::Element::rebuildLayoutTree()
#11 0x00000960c243 blink::Element::recalcOwnStyle()
#12 0x00000960b2c3 blink::Element::recalcStyle()
#13 0x0000094cec20 blink::ContainerNode::recalcDescendantStyles()
#14 0x00000960b59f blink::Element::recalcStyle()
#15 0x000009551f2e blink::Document::updateStyle()
#16 0x000009545b5f blink::Document::updateStyleAndLayoutTree()
#17 0x000009cc9c98 blink::FrameView::updateStyleAndLayoutIfNeededRecursiveInternal()
#18 0x000009cca72c blink::FrameView::updateStyleAndLayoutIfNeededRecursiveInternal()
#19 0x000009cc47e7 blink::FrameView::updateStyleAndLayoutIfNeededRecursive()
#20 0x000009cc2be4 blink::FrameView::updateLifecyclePhasesInternal()
#21 0x00000ac6a368 blink::PageAnimator::updateAllLifecyclePhases()
#22 0x0000086204f0 blink::WebViewImpl::updateAllLifecyclePhases()
#23 0x00000e22baf7 cc::ProxyMain::BeginMainFrame()

Probably, the problem is preloader doesn't consider crossorigin attribute of <video> and preload the image no-cors (Step 1)?

Looks like a preload scanner bug. I'll take a look. +yoav as fyi

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

commit b5132796d548ab65d4b537f03f72969b93217833
Author: csharrison <csharrison@chromium.org>
Date: Fri Nov 04 20:03:48 2016

Ensure video poster preloads use the crossorigin attribute

Previously, the preload request is sent out no-cors even if crossorigin
attribute is present.

BUG= 658575 

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

[add] https://crrev.com/b5132796d548ab65d4b537f03f72969b93217833/third_party/WebKit/LayoutTests/http/tests/preload/preload-video-cors.html
[modify] https://crrev.com/b5132796d548ab65d4b537f03f72969b93217833/third_party/WebKit/Source/core/html/parser/HTMLPreloadScanner.cpp

Should be fixed. Please update the bug if this still repros for you.