17352 2008-02-13 15:13:30 -0800 Origin of a Document from a data: URI should match HTML5 2022-08-11 04:54:56 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) All All RESOLVED CONFIGURATION CHANGED https://bugs.webkit.org/show_bug.cgi?id=168022 P2 Normal --- 17331 1 aroben abarth abarth ahmad.saleem792 a.m.dussaq ap arthur bfulgham cdumez dbates fred.wang mail mcatanzaro mcdonald.ben mchouinard26 nicholas paulirish pbakaus rniwa robertc sam warner.andy wgh youennf oldest_to_newest 70576 0 aroben 2008-02-13 15:13:30 -0800 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). 70580 1 sam 2008-02-13 15:30:01 -0800 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. 399519 2 nicholas 2011-05-06 08:08:12 -0700 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." 701490 3 mcdonald.ben 2012-08-21 19:07:58 -0700 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. 710196 4 abarth 2012-09-01 01:11:41 -0700 It's not clear if we should change our behavior here. 710291 5 sam 2012-09-01 15:26:08 -0700 (In reply to comment #4) > It's not clear if we should change our behavior here. Agreed. 711067 6 pbakaus 2012-09-04 06:38:29 -0700 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 725613 7 165151 christoph.burgmer 2012-09-21 10:14:40 -0700 Created attachment 165151 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 1171459 8 a.m.dussaq 2016-03-06 14:32:05 -0800 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. 1174829 9 mchouinard26 2016-03-14 17:23:43 -0700 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. 1225323 10 warner.andy 2016-09-01 07:40:48 -0700 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. 1225337 11 youennf 2016-09-01 09:24:07 -0700 (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. 1225350 12 cdumez 2016-09-01 09:41:00 -0700 (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. 1225355 13 youennf 2016-09-01 09:49:11 -0700 Sure, can you list some of them here, particularly if related to images? 1227578 14 youennf 2016-09-08 02:53:55 -0700 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. 1279847 15 arthur 2017-02-22 03:55:14 -0800 (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, 1398336 16 aman62 2018-02-12 02:31:00 -0800 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. 1890554 17 ahmad.saleem792 2022-08-11 04:54:45 -0700 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! 165151 2012-09-21 10:14:40 -0700 2012-09-21 10:14:40 -0700 Test case for bug in Webkit where writing a SVG to a canvas will make it impossible to read from webkitCanvasSameDomainBug.html text/html 1992 christoph.burgmer PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KICAgIDxtZXRhIGNoYXJzZXQ9InV0Zi04IiAv PgogICAgPHRpdGxlPlRlc3QgY2FzZSBmb3IgYnVnIGluIFdlYmtpdCB3aGVyZSB3cml0aW5nIGEg U1ZHIHRvIGEgY2FudmFzIHdpbGwgbWFrZSBpdCBpbXBvc3NpYmxlIHRvIHJlYWQgZnJvbTwvdGl0 bGU+CjwvaGVhZD4KPGJvZHk+CiAgICA8c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CiAg ICAgICAgZnVuY3Rpb24gbG9hZEltYWdlKHVybCwgY2FsbGJhY2spIHsKICAgICAgICAgICAgdmFy IGltYWdlID0gbmV3IHdpbmRvdy5JbWFnZSgpOwogICAgICAgICAgICBpbWFnZS5vbmxvYWQgPSBm dW5jdGlvbigpIHsKICAgICAgICAgICAgICAgIGNhbGxiYWNrKGltYWdlKTsKICAgICAgICAgICAg fTsKICAgICAgICAgICAgaW1hZ2Uuc3JjID0gdXJsOwogICAgICAgIH0KCiAgICAgICAgZnVuY3Rp b24gZHJhd1VybFRvQ2FudmFzKHVybCwgY2FudmFzLCBjYWxsYmFjaykgewogICAgICAgICAgICB2 YXIgY29udGV4dCA9IGNhbnZhcy5nZXRDb250ZXh0KCIyZCIpOwoKICAgICAgICAgICAgbG9hZElt YWdlKHVybCwgZnVuY3Rpb24gKGltYWdlKSB7CiAgICAgICAgICAgICAgICBjb250ZXh0LmNsZWFy UmVjdCgwLCAwLCBjYW52YXMud2lkdGgsIGNhbnZhcy5oZWlnaHQpOwogICAgICAgICAgICAgICAg Y29udGV4dC5kcmF3SW1hZ2UoaW1hZ2UsIDAsIDApOwoKICAgICAgICAgICAgICAgIGNhbGxiYWNr KCk7CiAgICAgICAgICAgIH0pOwogICAgICAgIH0KCiAgICAgICAgZnVuY3Rpb24gcmVhZEZyb21D YW52YXMoY2FudmFzKSB7CiAgICAgICAgICAgIHJldHVybiBjYW52YXMuZ2V0Q29udGV4dCgiMmQi KS5nZXRJbWFnZURhdGEoMCwgMCwgY2FudmFzLndpZHRoLCBjYW52YXMuaGVpZ2h0KTsKICAgICAg ICB9CgogICAgICAgIHdpbmRvdy5vbmxvYWQgPSBmdW5jdGlvbiAoKSB7CiAgICAgICAgICAgIHZh ciBhU3ZnSW1hZ2VVcmwgPSAnZGF0YTppbWFnZS9zdmcreG1sO2NoYXJzZXQ9dXRmLTgsPHN2ZyB4 bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIxMDAiIGhlaWdodD0iMTAw Ij48L3N2Zz4nOwoKICAgICAgICAgICAgbG9hZEltYWdlKGFTdmdJbWFnZVVybCwgZnVuY3Rpb24g KGltZykgewogICAgICAgICAgICAgICAgdmFyIGNhbnZhcyA9IGRvY3VtZW50LmNyZWF0ZUVsZW1l bnQoImNhbnZhcyIpOwoKICAgICAgICAgICAgICAgIGNhbnZhcy53aWR0aCA9IGltZy53aWR0aDsK ICAgICAgICAgICAgICAgIGNhbnZhcy5oZWlnaHQgPSBpbWcuaGVpZ2h0OwoKICAgICAgICAgICAg ICAgIGRyYXdVcmxUb0NhbnZhcygKICAgICAgICAgICAgICAgICAgICBhU3ZnSW1hZ2VVcmwsCiAg ICAgICAgICAgICAgICAgICAgY2FudmFzLAogICAgICAgICAgICAgICAgICAgIGZ1bmN0aW9uICgp IHsKICAgICAgICAgICAgICAgICAgICAgICAgdHJ5IHsKICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHJlYWRGcm9tQ2FudmFzKGNhbnZhcyk7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBj b25zb2xlLmxvZygicGFzcyIpOwogICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9jdW1lbnQu Z2V0RWxlbWVudHNCeVRhZ05hbWUoImJvZHkiKVswXS5zdHlsZS5iYWNrZ3JvdW5kQ29sb3IgPSAi Z3JlZW4iOwogICAgICAgICAgICAgICAgICAgICAgICB9IGNhdGNoIChlKSB7CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBjb25zb2xlLmxvZygiZmFpbCIpOwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgZG9jdW1lbnQuZ2V0RWxlbWVudHNCeVRhZ05hbWUoImJvZHkiKVswXS5zdHlsZS5i YWNrZ3JvdW5kQ29sb3IgPSAicmVkIjsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRocm93 IGU7CiAgICAgICAgICAgICAgICAgICAgICAgIH0KICAgICAgICAgICAgICAgICAgICB9KTsKICAg ICAgICAgICAgfSk7CiAgICAgICAgfTsKICAgIDwvc2NyaXB0Pgo8L2JvZHk+CjwvaHRtbD4K