Bug 17352 - Origin of a Document from a data: URI should match HTML5
Summary: Origin of a Document from a data: URI should match HTML5
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Adam Barth
URL:
Keywords:
Depends on:
Blocks: 17331
  Show dependency treegraph
 
Reported: 2008-02-13 15:13 PST by Adam Roben (:aroben)
Modified: 2018-02-13 10:17 PST (History)
19 users (show)

See Also:


Attachments
Test case for bug in Webkit where writing a SVG to a canvas will make it impossible to read from (1.95 KB, text/html)
2012-09-21 10:14 PDT, Christoph Burgmer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Roben (:aroben) 2008-02-13 15:13:30 PST
According to HTML5 <http://www.whatwg.org/specs/web-apps/current-work/#origin0>:

> The origin of a Document or image that was generated from a data: URI
> from another source is a globally unique identifier assigned when the
> document is created.

Where "from another source" means "not from another Document or script".

Currently we always assign a scheme/host/port tuple as the origin of a Document (though I'm not sure what the parts of this tuple end up being for a data: URI).
Comment 1 Sam Weinig 2008-02-13 15:30:01 PST
We currently mark data: URIs as having no access to any other origins including other data: URIs.  Our current policy is more restrictive than what HTML5 proposes.  We should consider relaxing it. 
Comment 2 Nicholas Wilson 2011-05-06 08:08:12 PDT
Please do relax it at some point to comply with HTML5. There is a small number of odd tasks designers use iframes with data URIs for. Having to faff with messages just for WebKit to let them communicate with the parent is a nuisance.

Usually, the origin of a Document from a data: URI should be that of the parent (or preceding page, given that you can make clickable data URIs with arbitrarily nested documents...)
> "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."
Comment 3 mcdonald.ben 2012-08-21 19:07:58 PDT
Would be great if this can be relaxed to comply with HTML5 as this bug prevents PNG downloads of SVG images in a handful of webapps.
Comment 4 Adam Barth 2012-09-01 01:11:41 PDT
It's not clear if we should change our behavior here.
Comment 5 Sam Weinig 2012-09-01 15:26:08 PDT
(In reply to comment #4)
> It's not clear if we should change our behavior here.

Agreed.
Comment 6 Paul Bakaus 2012-09-04 06:38:29 PDT
Definitely in favor of relaxing it. For a perfectly valid use case, see my new library Domvas at http://pbakaus.github.com/domvas/, using SVG's foreignObject to paint DOM content onto a canvas.

I have also opened a duplicate ticket on the Chromium bugtracker: http://code.google.com/p/chromium/issues/detail?id=145939
Comment 7 Christoph Burgmer 2012-09-21 10:14:40 PDT
Created attachment 165151 [details]
Test case for bug in Webkit where writing a SVG to a canvas will make it impossible to read from

I am unclear what content we are talking about here, and whether this is the right report for the issue I have when drawing SVG through a data:uri to a canvas. 

I am attaching a test case to test whether a canvas can be read once a SVG has been drawn from a data:uri. You should see a green page when the test case passes.

Btw. the original link to the HTML5 document is broken, here is the current one: http://www.whatwg.org/specs/web-apps/current-work/#origin-0
Comment 8 a.m.dussaq 2016-03-06 14:32:05 PST
Is there an update on this? Both Chrome and Firefox have expected behavior in this regard. It seems odd that in the case of trying to convert svg to png on a file with the proper domain origin this will not work. Additionally it causes the functions used by rasterizeHTML to fail to be able to build a dataURL from the image created.
Comment 9 mchouinard26 2016-03-14 17:23:43 PDT
Would love to see this implemented to match the same functionality as Chrome and Firefox.

There doesn't seem to be a workaround to get this to work in Webkit otherwise.
Comment 10 Andy Warner 2016-09-01 07:40:48 PDT
Any updates on this bug? Its been a few years and seems to still be an issue. We developers are running into this issue in the wild and only in webkit browsers. It would be nice to not have to fall back to something else because webkit cant keep up.
Comment 11 youenn fablet 2016-09-01 09:24:07 PDT
(In reply to comment #10)
> Any updates on this bug? Its been a few years and seems to still be an
> issue. We developers are running into this issue in the wild and only in
> webkit browsers. It would be nice to not have to fall back to something else
> because webkit cant keep up.

There is some recent work being done to improve that part.
Plan is to match fetch algorithm, thus making data URL resources have the same origin as the requester.

If you know some problematic web sites (or better test cases), I'll be glad to look at them.
Comment 12 Chris Dumez 2016-09-01 09:41:00 PDT
(In reply to comment #11)
> (In reply to comment #10)
> > Any updates on this bug? Its been a few years and seems to still be an
> > issue. We developers are running into this issue in the wild and only in
> > webkit browsers. It would be nice to not have to fall back to something else
> > because webkit cant keep up.
> 
> There is some recent work being done to improve that part.
> Plan is to match fetch algorithm, thus making data URL resources have the
> same origin as the requester.
> 
> If you know some problematic web sites (or better test cases), I'll be glad
> to look at them.

Youenn, if it helps, I know of web-platform-tests that are failing because of this.
Comment 13 youenn fablet 2016-09-01 09:49:11 PDT
Sure, can you list some of them here, particularly if related to images?
Comment 14 youenn fablet 2016-09-08 02:53:55 PDT
See https://github.com/whatwg/html/issues/1753 for ongoing discussions about document origin. Plan is to align the spec here with Chromium/WebKit

As of images, the same-origin data-url flag is set for img elements.
This means they are considered CORS-SameOrigin.
I think WebKit is aligned with this behavior also.

I am not sure if there is any other point to consider here.
Comment 15 Arthur Jamain 2017-02-22 03:55:14 PST
(In reply to comment #14)
> See https://github.com/whatwg/html/issues/1753 for ongoing discussions about
> document origin. Plan is to align the spec here with Chromium/WebKit
> 
> As of images, the same-origin data-url flag is set for img elements.
> This means they are considered CORS-SameOrigin.
> I think WebKit is aligned with this behavior also.
> 
> I am not sure if there is any other point to consider here.

Hey there !

I've just run into the foreignObject -> tainted canvas issue and have landed here. We're trying to build webGL UI components using HTML for VR browsing, and we have just realised that the resulting textures are actually tainted and hence unusable. I'm now trying to plan for an efficient workaround.

Do you have any ideas as to whether this will be eventually supported ? With maybe some kind of wide-ranging timeframe ?

I'm asking because as you've said a couple posts up, there seems to be some movement again around this issue. I'm trying to determine whether we can wait for a possible resolution with a temporary hack or if we need to find a hard workaround.

That being said, if our case is of any interest to you, I can provide a scoped test case. The rationale is : 

- interpolate a template with strings that are related to the user selecting stuff in webgl/VR scene ( strings are all dynamical / API provided )
- put resulting template in a svg / foreignObject
- generate an image based on this svg
- use this image as a texture for the webgl scene

Thanks for reading,
Comment 16 Aman Vishnani 2018-02-12 02:31:00 PST
Hi there,

Any progress on this bug? I came across this bug while using dom-to-image library for converting an HTML element into a sharable png image. I was hoping that we could make this work without restrictions since Google Chrome and Firefox already allows it.