- From: Mihai Parparita <mihaip@chromium.org>
- Date: Tue, 8 Feb 2011 15:07:09 -0800
I believe you're running into http://crbug.com/58999 Mihai On Tue, Feb 8, 2011 at 3:01 PM, Andreas G?bel <andreas.goebel at typeofnan.com> wrote: > > Am 08.02.2011 um 23:49 schrieb Diego Perini: > >> On Tue, Feb 8, 2011 at 10:38 PM, Andreas G?bel >> <andreas.goebel at typeofnan.com> wrote: >>> Recently I needed to have some base64 encoded images to show in a new window. My first attempt was, to just pass the data:image/png;base64,<data> string as first argument from window.open(). >>> >>> This works in all browsers that support data-uris, but it is terribly slowing down the browser when passing in images with a "big" filesize. My idea was to do something like this: >>> >>> var largeprev = window.open('data:text/html;charset=utf-8,' + escape('<div/>'), 'large'), >>> ? ?that ? ? ?= this; >>> >>> ? ?largeprev.addEventListener('DOMContentLoaded', function(e) { >>> ? ? ? ?largeprev.alert('loaded'); >>> ? ? ? ?largeprev.document.querySelectorAll('div')[0].appendChild(that); >>> ? ?}, false); >>> this works great in Firefox (3.6.x), but Chrome and Safari treat the returned DOMWindow object like it represents a foreign domain. Technically, it is not the same domain obviously since I'm passing in a data:text/html data-uri, but I would be shocked if the Same Origin Policy would deny an attempt like this ? >>> >>> What should be the correct behavior for this ? >>> >>> --Andy >>> >>> >> >> >> If I recall correctly "data:" and "javascript:" resources should >> inherit the "document.domain" from the environment in which they were >> encountered. So there should be no SOP blocking in accessing these >> resources. >> >> I have had bad experience with Chrome too with the "data:" URI. You >> can try to start the Chrome application using the >> "--allow-file-access-from-files" command line switch and see if this >> solves your problem. >> >> Some of the things that can be done in all other browsers need that >> special startup switch to enable the same behavior in Chrome. >> >> -- >> Diego > > > Well it's not an option for me to use a browser setting / commandline argument to make this work. The only way I'm aware of > is to use document.write() like > > > ? ? ? ?var virtualdom = '<html><body><img src="' + 'data:image/png;base64,R0lDWRW...' + '"/></body></html>', > ? ? ? ? ? ?prev ? ? ? = window.open('', 'large'); > > ? ? ? ?prev.document.open(); > ? ? ? ?prev.document.write(virtualdom); > ? ? ? ?prev.document.close(); > > in order to make this work. But I don't really like the approach. I think the behavior from Firefox is pretty correct (not to apply the SOP). > >
Received on Tuesday, 8 February 2011 15:07:09 UTC