Folks - I've attached a testcase that shows that localStorage, as its currently implemented, is not working for pages loaded from file:// URLs or from a local web server (i.e. 'localhost'). I filed a comment on this Mozilla bug (comment #9) wherein I note that the HTML5 specification has the concept of a 'file://' origin - therefore this feature should work for these kinds of origins too. No idea why 'http://localhost' is failing. Obviously, the way to run this testcase is to bring the page up, set the value, verify that the value is set, quit your browser, restart and click the button to show the value. Thanks!! Cheers, - Bill
Created attachment 23229 [details] Testcase showing localStorage not working for file:// or http://localhost URLs
Forgot to attach the Mozilla bug URL (my comment is #9) https://bugzilla.mozilla.org/show_bug.cgi?id=422526 Cheers, - Bill
As far as I can tell, each file:// url should be its own origin. Can you please confirm this is correct? I'll look into fixing this in the next couple days (or possibly as part of this work: https://bugs.webkit.org/show_bug.cgi?id=25376).
(In reply to comment #3) > As far as I can tell, each file:// url should be its own origin. Can you > please confirm this is correct? That is incorrect. All file URLs inhabit the same origin. Yes, that's a bit unfortunate.
That is unfortunate. FYI, this is why I thought it might be per file: https://developer.mozilla.org/En/Same-origin_policy_for_file:_URIs I guess Mozilla is breaking from the spec?
(In reply to comment #5) > FYI, this is why I thought it might be per file: > https://developer.mozilla.org/En/Same-origin_policy_for_file:_URIs I guess > Mozilla is breaking from the spec? Many of the browser vendors would like to lock down file URL access more. Mozilla is experimenting with a tighter security policy. My understanding is that their experiment is fairly successful. It might be getting to be time to revisit this issue more broadly. For this patch, though, we should stick with WebKit's current security policy. We can always change it later if and when we revise the access policy for file URLs in general. (As for what the specs say, they are silent on this point. More precisely, they say the behavior is implementation-defined.)
I tried this out on my mac with the nightly build and it all works as expected (including all files sharing the same localStorage namespace). I don't think there's anything left to do here, but I don't have permissions to close the bug.
Marking as fixed per comment #7.