Bug 17352

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.

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."

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.

It's not clear if we should change our behavior here.

(In reply to comment #4) > It's not clear if we should change our behavior here. Agreed.

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

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

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.

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.

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.

(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.

(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.

Sure, can you list some of them here, particularly if related to images?

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.

(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,

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.

I am unable to reproduce this bug using attached test case in Safari 15.6 on macOS 12.5 and it shows "Green" page, which is indication of "PASS" as per Comment 07 but if the test is wrong then please ignore my comment and reopen this bug. While in case of other browser (Chrome Canary 106 and Firefox Nightly 105) also render the test in "Green".It also show "pass" in console for all other browsers. I am marking this as "RESOLVED CONFIGURATION CHANGED". Thanks!