W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2011

[whatwg] clarification for data-uris in window.open and SOP

From: Andreas Göbel <andreas.goebel@typeofnan.com>
Date: Wed, 9 Feb 2011 00:01:41 +0100
Message-ID: <7BA9CB85-39C7-4AF8-B649-789C772D70BA@typeofnan.com>

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:01:41 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:30 UTC