This can help to find a reason of bug:
> Sometimes you see in console that there is very little time when canvas is not tainted and with real image from video.
> Considering this, maybe this bug caused by additional requests with range.

Example of the case when "there is very little time when canvas is not tainted and with real image from video":
https://jsfiddle.net/sv7uoure/5/

As you see, when video loading screenshot is empty (size is 8490):
progress 0.726476
success. Size of screenshot: 8490
suspend 0.726476
success. Size of screenshot: 8490

After loading screenshot with real data from video (size is 250074):
timeupdate 0.726476
success. Size of screenshot: 250074
seeked 0.726476
success. Size of screenshot: 250074
loadeddata 0.726476
success. Size of screenshot: 250074
canplay 0.726476
success. Size of screenshot: 250074
canplaythrough 0.726476
success. Size of screenshot: 250074
timeupdate 0.726476
success. Size of screenshot: 250074
progress 0.726476

But after less than one second it becomes tainted:
success. Size of screenshot: 250074
progress 0.726476
success. Size of screenshot: 250074
progress 0.726476
error:  DOMException: Failed to execute 'toDataURL' on 'HTMLCanvasElement': Tainted canvases may not be exported.
suspend 0.726476
error:  DOMException: Failed to execute 'toDataURL' on 'HTMLCanvasElement': Tainted canvases may not be exported.

At the same time, Chrome makes about 5 requests with ranges 0-4024439, then 3997696-4024439, 32768-4024439, 65536-4024439, 98304-4024439.

Maybe after finising some of additional requests video mistakenly marked as tainted?

Able to reproduce the issue for chrome version 54.0.2836.0 on Windows 7, MAC 10.11.6, Ubuntu 14.04. Issue is a non regression seen from M24 - 24.0.1300.0.

Issue is not observed on FF browser. Untriaging it so that it gets addressed.

> Issue is a non regression seen from M24 - 24.0.1300.0.
It is working for me (no issue) in Chrome 49 and Chromium 49. Screenshot in attachment.

Deleted: test-49.png 90.4 KB

	test-49.png 90.4 KB View Download

Deleted: test-49-2.png 212 KB

	test-49-2.png 212 KB View Download

When I run this in debug mode, I get the following error:

[1:1:0823/164557:FATAL:multibuffer_data_source.cc(249)] Check failed: init_cb_.is_null() && reader_.get(). Initialize() must complete before calling HasSingleOrigin()
#0 0x7fe7fd92fdbe base::debug::StackTrace::StackTrace()
#1 0x7fe7fd99631f logging::LogMessage::~LogMessage()
#2 0x7fe7e7b86380 media::MultibufferDataSource::HasSingleOrigin()
#3 0x7fe7e7bc6055 media::WebMediaPlayerImpl::hasSingleSecurityOrigin()
#4 0x7fe7e42bbcc7 blink::HTMLMediaElement::hasSingleSecurityOrigin()
#5 0x7fe7e42af1e0 blink::HTMLMediaElement::isMediaDataCORSSameOrigin()
#6 0x7fe7e43182a8 blink::HTMLVideoElement::wouldTaintOrigin()
#7 0x7fe7e4341258 blink::CanvasRenderingContext::wouldTaintOrigin()
#8 0x7fe7e221ea7b blink::CanvasRenderingContext2D::wouldTaintOrigin()
#9 0x7fe7e2209948 blink::BaseRenderingContext2D::drawImage()
#10 0x7fe7e2209ae7 blink::BaseRenderingContext2D::drawImage()
#11 0x7fe7e28682f9 blink::CanvasRenderingContext2DV8Internal::drawImage2Method()
#12 0x7fe7e2866ecf blink::CanvasRenderingContext2DV8Internal::drawImageMethod()
#13 0x7fe7e2857b75 blink::CanvasRenderingContext2DV8Internal::drawImageMethodCallback()
#14 0x7fe7f397999c v8::internal::FunctionCallbackArguments::Call()
#15 0x7fe7f3a24def v8::internal::(anonymous namespace)::HandleApiCallHelper<>()
#16 0x7fe7f3a23c35 v8::internal::Builtin_Impl_HandleApiCall()
#17 0x7fe7f3a2393e v8::internal::Builtin_HandleApiCall()
#18 0x0fe7fd8063a7 <unknown>


I think we really need to re-design the tait/hassingleorigin call. Since the origin can become tainted at any point, polling it is not going to work very well. Especially not before we've even started the http request.

Perhaps this tainting should be attached to the video frames instead?

> Since the origin can become tainted at any point, polling it is not going to work very well.
If I understand correctly, video can't become tainted "in the middle" if it's loaded with "crossorigin" attribute.

For example if you are loading video with "crossorigin" attribute and there is no "Access-Control-Allow-Origin" in response then video just doesn't loads.
Live example https://jsfiddle.net/sv7uoure/6/ (you can see that video stops loading after "error" event).

That's true, and I still need to figure out what is actually going wrong here.
I was just pointing out that the way we poll the hasSingleSecurityOrigin() is flawed.

Hmm, not sure what's going on yet, the network layer and buffering code all reports a single security origin.

Bug found, fix on the way.

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

commit 5f8b274cdab547c8afff5429110a97d15353c19c
Author: hubbe <hubbe@chromium.org>
Date: Thu Aug 25 00:28:59 2016

Bugfix for cross-origin check

The code is mistaking a missing reader for an error, but readers are now destroyed and re-created on demand.
Adding a new variable to explicitly track failures fixes the problem.

BUG= 639690 

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

[modify] https://crrev.com/5f8b274cdab547c8afff5429110a97d15353c19c/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/5f8b274cdab547c8afff5429110a97d15353c19c/media/blink/multibuffer_data_source.h
[modify] https://crrev.com/5f8b274cdab547c8afff5429110a97d15353c19c/media/blink/multibuffer_data_source_unittest.cc

Thank you for the fast fix :-)

The crash from #6 is still occurring for me even with the patch from comment #11, I have a reproducible test case for it but it's at an internal URL. hubbe@, I'll send you the link separately.

FYI, my test page works normally if I just comment out the failing DCHECK in HasSingleOrigin, but that's of course not suitable as a real fix.

#6 is really a separate problem and should have it's own bug.

[Automated comment] Less than 2 weeks to go before stable on M53, manual review required.

M53 is VERY close to  Stable launch and bar is very high. We can take this change only if it is critical, well baked/verified in Canary and safe to merge. Please confirm. Thank you.

The CL is small, simple and safe. It's been in canary for a day.
I'd say the risk is very low.

I'm not entirely sure how critical it is, as the use case is somewhat rare (video element data readback through a canvas where the video is cross-origin).

Since I don't know how common a use case it is, but the risk is low, I would argue that we should merge the fix instead of risking a lot more bug reports later, but obviously the decision is up to you.

Approving merge to M53 branch 2785 based on comment #19. Please merge ASAP. Merge has to happen before 4:00 PM PT  Monday in order to make into the desktop Stable final build cut.Thank you.

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

commit 9e81a357b3656f2eed03c9bbfda106eb892d9ae8
Author: Fredrik Hubinette <hubbe@google.com>
Date: Fri Aug 26 21:43:15 2016

Cherrypick Bugfix for cross-origin check

The code is mistaking a missing reader for an error, but readers are now destroyed and re-created on demand.
Adding a new variable to explicitly track failures fixes the problem.

Original commit:  https://crrev.com/5f8b274cdab547c8afff5429110a97d15353c19c

BUG= 639690 

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

Cr-Commit-Position: refs/branch-heads/2785@{#766}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/9e81a357b3656f2eed03c9bbfda106eb892d9ae8/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/9e81a357b3656f2eed03c9bbfda106eb892d9ae8/media/blink/multibuffer_data_source.h
[modify] https://crrev.com/9e81a357b3656f2eed03c9bbfda106eb892d9ae8/media/blink/multibuffer_data_source_unittest.cc

Verified this issue on Windows-10, Mac OS 10.11.6 and Ubuntu 14.04 using chrome latest Dev M54-54.0.2840.0 by following steps mentioned in the original comment. No errors are seen under console as mentioned in the comment #1 and all the screenshot displays true as expected. Hence adding TE-Verified label.

Deleted: 639690.mp4 6.5 MB

	639690.mp4 6.5 MB View Download

Verified this issue on Windows-10, Mac OS 10.11.6 and Ubuntu 14.04 using chrome latest Beta M53-53.0.2785.89. As mentioned in the comment #22 no errors are seen under console and all the screenshot displays true as expected. Hence adding TE-Verified label.

Deleted: Screen Shot 2016-08-31 at 2.22.22 PM.png 278 KB

	Screen Shot 2016-08-31 at 2.22.22 PM.png 278 KB View Download

I have cross verified the fix on Win 7 and compared to current stable channel i.e., 52.0.2743.116 with 53.0.2785.89, there are no error in M53(53.0.2785.89).