As a correction to the section of the report on the expected behavior, I had mistakenly assumed that turning off "security.fileuri.strict_origin_policy" in "about:config" would change the behavior of this as a workaround so that it worked more like I expected. However, in testing that just now, nothing has changed that I've noticed about the behavior under Firefox 29 or Firefox Nightly. Apparently that setting does not affect the IndexedDB behavior in this regard. So, there seems to be no way under Firefox at the moment that I know of to make a local-file-based single-page web application that uses the query string in a "file://..." bookmark or pasted-in link to select the desired subset of previously-added data in an IndexedDB database added under a different query string for the same file.
Hi Paul, Did you managed to find any workaround for this problem. My application works inside an iframe of different domain website and need access to local storage. Any help would be highly appreciated. Thanks
This IndexedDB issue reported for FireFox 29.0 seems to be fixed as of FireFox 40.0.2 (or likely earlier, but I just noticed it working now). So I am marking this issue resolved/worksforme. Another workaround for my use case could have been to use a hash ("#id=foo") instead of a query string ("?id=foo") on the assumption hashs are treated differently for resolving same origins. That also works with 40.0.2, however I did not test that with earlier versions of FireFox where I'm just assuming it would work. @Neeraj I think the issue you mentioned (iframe use and local storage) is a different issue. You could possibly solve it by using postMessage to sending messages between windows. https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
For me this issue persists on 41.0.1 with a fragment (hash) in the URL. I guess I'll open a new issue then.