SecurityOrigin for a file URL returns "file://", and SecurityOrigin::createFromString("file://") creates a unique (null) security origin (because "file://" is first canonicalized to "file:///" and that is a directory). This means the conversion SecurityOrigin -> string -> SecurityOrigin doens't give back the same SecurityOrigin in case of file URLs. WebStorageNamespaceImpl::createStorageArea contains a workaround which changes the string "file://" into "file:///a" before giving it to SecurityOrigin::createFromString. If SecurityOrigin::m_enforceFilePathSeparation is true, then SecurityOrigin::toString() returns "null" for file URLs, and this problem does not exist, and the workaround code is not ran. This bug is for trying out what breaks if the workaround is removed. I'll submit a patch which just removes it, to see whether there are any tests that rely on the workaround code.
Created attachment 103347 [details] Removing the workaround.
(In reply to comment #0) > This bug is for trying out what breaks if the workaround is removed. I'll submit a patch which just removes it, to see whether there are any tests that rely on the workaround code. I'd expect the test failures to be mainly when running layout tests in Chromium, so you'll need to apply this patch to a checkout of chromium and run the tests there (webkit/tools/layout_tests/run_webkit_tests.py and probably browser_tests)
(In reply to comment #2) > I'd expect the test failures to be mainly when running layout tests in Chromium, so you'll need to apply this patch to a checkout of chromium and run the tests there (webkit/tools/layout_tests/run_webkit_tests.py and probably browser_tests) Yep. Removing the workaround didn't add any (relevant) test failures there either.
(In reply to comment #3) > (In reply to comment #2) > > I'd expect the test failures to be mainly when running layout tests in Chromium, so you'll need to apply this patch to a checkout of chromium and run the tests there (webkit/tools/layout_tests/run_webkit_tests.py and probably browser_tests) > > Yep. Removing the workaround didn't add any (relevant) test failures there either. ok, the patch looks good, you should mark it r? c?, maybe Adam can do the actual review then
Comment on attachment 103347 [details] Removing the workaround. This looks great, but we'll need a ChangeLog.
Created attachment 103648 [details] Patch for landing
I added a ChangeLog for you.
Comment on attachment 103648 [details] Patch for landing Clearing flags on attachment: 103648 Committed r92872: <http://trac.webkit.org/changeset/92872>
All reviewed patches have been landed. Closing bug.