Accessing relative URL's via "ajax" from "file://" content

Question

I'm putting together some demo pages, and one of the things I want to demonstrate involves fetching HTML fragments dynamically with subsequent processing. Thus I've got simple jQuery code like this:

$('#target').load('./content_fragment.html', function() {
  $(this).doSomething();
});

I'm doing all this from file:// URLs because the whole thing is part of a presentation that I (might) run from a thumb drive or something. Thus, "content_fragment.html" is just another local file, just like the main page that contains that code.

Now this all works just fine from Firefox or Safari, and other uses of relative URLs work fine in Chrome (iframe "src" URLs, images, scripts, css, etc), but Chrome just won't pay attention to those ".load()" requests at all. If I zip up the content and deploy it to a web server, and then get at it via its "http:" URL, then Chrome works fine. When it doesn't work, I don't see any errors in the Chrome console; it just doesn't fetch the content. I've tried it with Chrome on Linux and XP, with identical results. (And Safari or Firefox to the same file:// URLs always do what I expect and load the content.)

So my question is, is this weirdness just a Chrome quirk, or is there something inherently questionable about XMLHttpRequests and file:// URLs? In other words, is Chrome doing the right thing, meaning the other browsers are broken?

Answer 1

You can add --allow-file-access-from-files to the command line when launching chrome to disable this security feature :)

Is it a bug? Maybe, maybe not, what's happening is it's not treating file:// as a single domain, requests to a different file are treated as a different domain and therefore blocked by the SOP rules. It's a choice by the Chrome/Chromium developers, whether it's the correct one depends on your point of view I suppose.

There's a lot of dicusssion on this in the Chrome issues section on Google code, you may find the discussion of interest, here and here.