- From: Diego Perini <diego.perini@gmail.com>
- Date: Tue, 8 Feb 2011 23:49:34 +0100
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