Bug 29305 - Canvas drawn with data URL image raises SECURITY_ERR when toDataUrl() called.
: Canvas drawn with data URL image raises SECURITY_ERR when toDataUrl() called.
Status: RESOLVED FIXED
Product: WebKit
Classification: Unclassified
Component: HTML DOM
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To: Nobody
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-16 10:44 PDT by Adam Barth
Modified: 2009-12-29 14:51 PST (History)
7 users (show)

See Also:


Attachments
Patch v1 (14.53 KB, patch)
2009-09-19 09:46 PDT, Adam Barth
oliver: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Barth 2009-09-16 10:44:12 PDT
Importing issue http://code.google.com/p/chromium/issues/detail?id=21847

Reported by btlee@google.com, Yesterday (36 hours ago)
Chrome Version       : 4.0.206.1 (Official Build 25376)
URLs (if applicable) : http://members.shaw.ca/briantclee/canvas.html
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: FAIL. 
  Firefox 3.x: OK
     Opera 10: OK
         IE 7: FAIL. Canvas not supported.
         IE 8: FAIL. Canvas not supported.


What steps will reproduce the problem?
1. Have a webpage:
   1. Create an Image from a data URL.
   2. Create a canvas.
   3. Draw the image to the canvas.
   4. Call canvas.toDataURL().
2. Launch the webpage.


What is the expected result?
toDataURL() returns a data URL for the image drawn to the canvas.

What happens instead?
Error in the console: "Uncaught Error: SECURITY_ERR: DOM Exception 18". 

Drawing from an image with source being a data URL seems to set the
origin-clean flag false. I don't think this should be although it doesn't
explicitly mention this in
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html
Comment 1 Sam Weinig 2009-09-16 13:08:46 PDT
We should make sure to test svg data urls to make sure they don't get through.
Comment 2 Adam Barth 2009-09-16 18:35:52 PDT
(In reply to comment #1)
> We should make sure to test svg data urls to make sure they don't get through.

You mean something like data:text/svg,<svg>...
?

Why shouldn't that get through?
Comment 3 Oliver Hunt 2009-09-16 21:35:26 PDT
(In reply to comment #2)
> (In reply to comment #1)
> > We should make sure to test svg data urls to make sure they don't get through.
> 
> You mean something like data:text/svg,<svg>...
> ?
> 
> Why shouldn't that get through?

The specific issue i think is that you can do

data:application/xml+svg,<svg><image src="evil.com"/></svg>

or whatever.  However i *think* we would catch that as being a multi-origin source.  I think Sam's point was that we need to have a test that ensures the correct restrictions are in place.
Comment 4 Adam Barth 2009-09-19 08:57:52 PDT
This is fallout from our treatment of data URLs being different than required by the HTML5 spec:

===
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 in which the data: URL was found.
===

We'll want to think carefully before adopting this requirement, but I think we can fix the canvas behavior independently.
Comment 5 Adam Barth 2009-09-19 09:46:13 PDT
Created attachment 39820 [details]
Patch v1
Comment 6 Oliver Hunt 2009-09-19 09:49:47 PDT
Comment on attachment 39820 [details]
Patch v1

r=me, we should fix tracking of data url origin as well i guess
Comment 7 Adam Barth 2009-09-19 09:56:34 PDT
Thanks for the review.  I think Maciej has strong opinions about the data URL / noAccess thing.  We'd definitely want to talk with him before changing it.
Comment 8 Evan Martin 2009-09-19 09:59:11 PDT
+        Test that drawing a data URL image onto a canvas behaves as expected.
+        Note the tricky case involving an data URL SVG image with an embedded
+        remote image.

Typo: "an data URL".
Comment 9 Adam Barth 2009-09-19 10:06:15 PDT
> Typo: "an data URL".

Thanks.  I'll fix it on landing.
Comment 10 Adam Barth 2009-09-19 10:17:32 PDT
Committed r48556: <http://trac.webkit.org/changeset/48556>
Comment 11 Adam Barth 2009-09-19 10:19:38 PDT
*** Bug 17150 has been marked as a duplicate of this bug. ***
Comment 12 Peter van der Zee 2009-12-29 13:27:39 PST
Hi. It seems this problem is back. Tested in nightly WebKit-r52593 on Windows. Given testcase does not show data url. Problem seems to be fixed in nightly Chrome build (r30453) though.
Comment 13 Adam Barth 2009-12-29 14:00:39 PST
Can you file a new bug and CC the relevant folks?  Odd that the test didn't catch the regression...
Comment 14 Peter van der Zee 2009-12-29 14:51:38 PST
See Bug 33029