Bug 34298 - [Chromium] StorageNamespaceProxy::copy() should be a no-op
Summary: [Chromium] StorageNamespaceProxy::copy() should be a no-op
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other OS X 10.5
: P2 Normal
Assignee: Jeremy Orlow
Depends on:
Reported: 2010-01-28 18:15 PST by Jeremy Orlow
Modified: 2010-01-28 23:15 PST (History)
1 user (show)

See Also:

Patch (1.66 KB, patch)
2010-01-28 18:22 PST, Jeremy Orlow
fishd: review+
fishd: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Orlow 2010-01-28 18:15:59 PST
StorageNamespaceProxy::copy() should be a no-op
Comment 1 Jeremy Orlow 2010-01-28 18:22:17 PST
Created attachment 47664 [details]
Comment 2 Jeremy Orlow 2010-01-28 19:01:24 PST
It's worth noting the current behavior asserts NOT REACHED when m_storageNamespace->copy() is called.  :-)
Comment 3 Darin Fisher (:fishd, Google) 2010-01-28 22:55:38 PST
Comment on attachment 47664 [details]

> +    // The WebViewClient knows what its session storage namespace id is but we
> +    // do not.  Returning 0 here causes it to be fetched (via theWebViewClient)

nit: "theWebViewClient" -> "the WebViewClient"

> +    // on its next use.  Note that it is WebViewClient::createView's
> +    // responsibility to clone the session storage namespace id and that the
> +    // only time copy() is called is directly after the createView call...which
> +    // is why all of this is safe.

nit: It seems like some of this should be documented on WebViewClient::createView.


Feel free to fixup comments and commit.
Comment 4 Jeremy Orlow 2010-01-28 23:15:43 PST
Committed r54046: <http://trac.webkit.org/changeset/54046>