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

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

From: Diego Perini <diego.perini@gmail.com>
Date: Tue, 8 Feb 2011 23:49:34 +0100
Message-ID: <AANLkTi=GR_p1wf1M5juyWcGMob79PCbkBhqT2H1hB2Yb@mail.gmail.com>
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
Received on Tuesday, 8 February 2011 14:49:34 UTC

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