[whatwg] clarification for data-uris in window.open and SOP
Diego Perini
diego.perini at gmail.com
Tue Feb 8 14:49:34 PST 2011
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
More information about the whatwg
mailing list