604496 - Security Error with toDataURL on a canvas with drawImage on a video loaded from a data URL

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[antimatter15]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/7.0.544.0 Safari/534.10
Build Identifier: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0b6) Gecko/20100101 Firefox/4.0b6

I'm working on a javascript WebP -> WebM conversion library and for a multitude of reasons, it would be nice to convert the video back into an image through canvas, but firefox always gives a security exception after calling toDataURL. I think it's something like the cross-origin image loading issues with canvas, but I don't believe data urls count as a different domain. Chrome allows this behavior and I believe Opera too.

Reproducible: Always

Steps to Reproduce:
1. Have a <video> tag that has a src set to a data: url
2. drawImage(video) to the canvas
3. call toDataURL('image/png') or getImageData() and observe exception
Actual Results:  
[Exception... "Security error"  code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)"  location: "file:///home/antimatter15/testcase.html Line: 1"]

Expected Results:  
A long data url

Comment 1

[antimatter15]

Attachment: Test case (uses webm video, so probably firefox 4+ only)

Comment 2

[Boris Zbarsky [:bzbarsky]]

> but I don't believe data urls count as a different domain

They do, in general; unless otherwise special-cased.  <video> doesn't thus special-case them.

Comment 3

[Boris Zbarsky [:bzbarsky]]

In particular, the HTML5 spec for origins is very clear, and data:something is a different origin from http:// anything because the schemes are different.  So a behavior change here would need a spec change too.

Comment 4

[antimatter15]

Interesting.

From http://dev.w3.org/html5/spec/Overview.html#same-origin

If a Document or image was generated from a data: URL found in another Document or in a script
    The origin is the origin of the Document or script that initiated the navigation to that URL.

I'm not exactly sure what that means, but it seems to me that this means (in this case) the origin should be the same.

Comment 5

[Boris Zbarsky [:bzbarsky]]

That only applies to documents and images, though....  We apply it to documents but not yet to images.  And the spec language doesn't apply to <video>.

Now maybe what's needed here is a spec change, of course.

Comment 7

[Lari Temmes]

I'm trying to stream live video and do some pixel manipulation for video canvas. Video feed comes from localhost (it has domain name, pointing to 127.0.0.1) and HTML part from internet. That makes getImageData() fail. There should be config option to disable security checking for videos and other media files.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Lari, that's completely unrelated to this bug.

Can you please raise a spec issue on adding something like the 'crossorigin' attribute to video elements?

Comment 9

[Boris Zbarsky [:bzbarsky]]

Looks like the spec here has changed so now data: videos are supposed to inherit the origin.  Specifically, the origin of "audio and video elements" is defined as:

  If the media data is CORS-same-origin
    The origin is an alias to the origin of the media element's node document.

and under https://html.spec.whatwg.org/multipage/infrastructure.html#cors-enabled-fetch all data: loads are treated as CORS-same-origin.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Inherit the document principal for data: media elements

This fixes the testcase in this bug, but I'm pretty sure that only hits the HTMLMediaElement codepath.  I'd really appreciate help with writing tests for this that cover all three codepaths...

Comment 11

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/624049a9b1aa

Comment 12

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/624049a9b1aa

Comment 14

[Alex Kowel]

Confirmed: this fixes the bug 1147884