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

Tue Feb 8 15:07:09 PST 2011

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