Commit d7e2048b authored by eric@webkit.org's avatar eric@webkit.org
Browse files

2009-11-24 Adam Barth <abarth@webkit.org>

        Reviewed by Dimitri Glazkov.

        [Chromium] Fix DOM storage layout tests
        https://bugs.webkit.org/show_bug.cgi?id=31833

        The issue is, essentially, that this code assumes that
        SecurityOrigin::createString can re-create a SecurityOrigin given
        the string produced from SecurityOrigin::toString.  This is a bogus
        assumption in a number of corner cases (e.g., document.domain,
        @sandbox).  A recent patch (http://trac.webkit.org/changeset/51294)
        make this assumption further invalid in the case of of file:// URLs.

        The correct fix is for this code to use WebSecurityOrigin objects
        (and not strings) to represent SecurityOrigin objects.  However, the
        expert on this code is on vacation, and I don't want to do major
        surgery here without his involvement.  This patch is a temporary fix
        to get these tests passing again.  We'll do the right fix once
        jorlow gets back from vacation.

        Tests: Covered by a number of existing DOM storage tests.

        * src/WebStorageNamespaceImpl.cpp:
        (WebKit::WebStorageNamespaceImpl::createStorageArea):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@51338 268f45cc-cd09-0410-ab3c-d52691b4dbfc
parent 0b8dd72a
2009-11-24 Adam Barth <abarth@webkit.org>
Reviewed by Dimitri Glazkov.
[Chromium] Fix DOM storage layout tests
https://bugs.webkit.org/show_bug.cgi?id=31833
The issue is, essentially, that this code assumes that
SecurityOrigin::createString can re-create a SecurityOrigin given
the string produced from SecurityOrigin::toString. This is a bogus
assumption in a number of corner cases (e.g., document.domain,
@sandbox). A recent patch (http://trac.webkit.org/changeset/51294)
make this assumption further invalid in the case of of file:// URLs.
The correct fix is for this code to use WebSecurityOrigin objects
(and not strings) to represent SecurityOrigin objects. However, the
expert on this code is on vacation, and I don't want to do major
surgery here without his involvement. This patch is a temporary fix
to get these tests passing again. We'll do the right fix once
jorlow gets back from vacation.
Tests: Covered by a number of existing DOM storage tests.
* src/WebStorageNamespaceImpl.cpp:
(WebKit::WebStorageNamespaceImpl::createStorageArea):
2009-11-23 Jian Li <jianli@chromium.org>
Reviewed by NOBODY (Chromium build fix).
......
......@@ -61,7 +61,20 @@ WebStorageNamespaceImpl::~WebStorageNamespaceImpl()
WebStorageArea* WebStorageNamespaceImpl::createStorageArea(const WebString& originString)
{
RefPtr<WebCore::SecurityOrigin> origin = WebCore::SecurityOrigin::createFromString(originString);
WebCore::String originWebCoreString = originString;
if (originWebCoreString == "file://") {
// FIXME: We should really be passing around WebSecurityOrigin objects
// to represent security origins instead of strings. One issue
// with using strings is that createFromString(toString) does
// not round-trip for file URLs because file:// looks like a
// directory (which is sandboxed).
//
// For the time being, we work around this issue by using "file:///a",
// which does not look like a directory. We should fix this when
// jorlow gets back from vactation.
originWebCoreString = "file:///a";
}
RefPtr<WebCore::SecurityOrigin> origin = WebCore::SecurityOrigin::createFromString(originWebCoreString);
return new WebStorageAreaImpl(m_storageNamespace->storageArea(origin.release()));
}
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment