1

I'm developer of Construct 2, a HTML5 game editor for Windows. It's at http://www.scirra.com.

Recently I've been trying to add a feature that will modify an image by transforming it on a canvas. It's pretty straightforward - draw an Image to the canvas and call getImageData() to get the pixels.

When the user clicks 'preview' in our application, all the files are dumped to a temp file on disk and a browser launched to show it. Uploading to a server is not an option for previewing - some games are megabytes big.

However most browsers block you using getImageData() to get the pixels of any image loaded from disk at all. I've tried putting all the necessary image files in subdirectories as MDN suggests in its description of file:// access policies. That doesn't work either!

Chrome's --allow-file-access-from-files flag fixes it. However, I need to support all major browsers. Is there a similar workaround for at least Internet Explorer and Firefox? I have no idea about Internet Explorer, and I really wish there's something which doesn't involve manually going to about:config in Firefox, otherwise we will be deluged in support requests asking "why doesn't it work in Firefox?!".

Also, why on earth is this security policy necessary?!? It seems way over the top and makes applications like ours really difficult to write.

Any help appreciated.

AshleysBrain
  • 22,335
  • 15
  • 88
  • 124

1 Answers1

3

Your name sounds familiar from HN.

This is pretty laid out in stone in the spec by now, though this upsets an awful lot of people. http:// and file:// are different origins, and anything that tries to put one on the other will dirty the origin. As you noted file uri's themselves have their own set of rules that make things even trickier.

Drawing something to a canvas whose origin is not the same? Too bad, the origin-clean flag henceforth is false, which then disallows you from doing various things.

A complete list of those things is located in the spec here.

But I'm sure you know all this by now. You want to get around it.

I'd suggest ins instead of trying to strong-arm the browsers around it, you bundle in some kind of lightweight web service so that things are all appearing from the same origin. It will cause a lot fewer headaches in the future.

You'll probably want something like the Python SimpleHTTPServer. But that decision really depends on what you've already got included in your product already at this point.

Simon Sarris
  • 62,212
  • 13
  • 141
  • 171
  • OK, nice idea with serving images from disk via a local http server. But it's kind of mad! I still don't get why a PNG in the same folder as a HTML file on disk counts as a different origin, and a PNG in the same folder as a HTML file on http counts as the same origin. I'd love to hear the rationale behind this. – AshleysBrain Jul 15 '11 at 17:21
  • the Chrome team actually made a detailed blog post about that back in 2008: http://blog.chromium.org/2008/12/security-in-depth-local-web-pages.html – Simon Sarris Jul 15 '11 at 18:11
  • thanks for the interesting link. However, I didn't see any rationale for not being able to read the pixels of images in the same directory as a page on disk. – AshleysBrain Jul 15 '11 at 18:29
  • The blanket decision that we both consider a pain is due to a historically large number of security problems where any locally stored HTML file was allowed to access all other files on the disk. According to Google, even allowing such a file to access files right next to itself in the document tree is a no-go. We call it over-the-top. They call it safe. :/ – Simon Sarris Jul 15 '11 at 18:38
  • I have gone as far as implementing a local HTTP server to serve files via the HTTP API built in to Windows. However, you have to have admin rights to start a HTTP server. Is there no solution for non-admin users?! – AshleysBrain Jul 16 '11 at 22:49
  • No worries, solved it in the end - http://stackoverflow.com/questions/6721153/httpaddurl-on-localhost-fails-for-non-admin-users/6724197#6724197 – AshleysBrain Jul 19 '11 at 20:50