2009-11-24 Adam Barth <abarth@webkit.org>
authoreric@webkit.org <eric@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 24 Nov 2009 16:15:54 +0000 (16:15 +0000)
committereric@webkit.org <eric@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 24 Nov 2009 16:15:54 +0000 (16:15 +0000)
commiteeb17832fe58c66e63886d4b4b48c8be87a3f057
treea787cc2ef07f57ffca6a7dede010768abf497d0f
parentc5e87b5b6285b87769f2344186dcbcea47b8c2e2
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: https://svn.webkit.org/repository/webkit/trunk@51338 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WebKit/chromium/ChangeLog
WebKit/chromium/src/WebStorageNamespaceImpl.cpp