Bug 34298

Summary: [Chromium] StorageNamespaceProxy::copy() should be a no-op
Product: WebKit Reporter: Jeremy Orlow <jorlow>
Component: New BugsAssignee: Jeremy Orlow <jorlow>
Status: RESOLVED FIXED    
Severity: Normal CC: fishd
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Other   
OS: OS X 10.5   
Attachments:
Description Flags
Patch fishd: review+, fishd: commit-queue-

Jeremy Orlow
Reported 2010-01-28 18:15:59 PST
StorageNamespaceProxy::copy() should be a no-op
Attachments
Patch (1.66 KB, patch)
2010-01-28 18:22 PST, Jeremy Orlow 		fishd: review+
fishd: commit-queue-
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Jeremy Orlow
Comment 1 2010-01-28 18:22:17 PST
Created attachment 47664 [details] Patch
Jeremy Orlow
Comment 2 2010-01-28 19:01:24 PST
It's worth noting the current behavior asserts NOT REACHED when m_storageNamespace->copy() is called. :-)
Darin Fisher (:fishd, Google)
Comment 3 2010-01-28 22:55:38 PST
Comment on attachment 47664 [details] Patch > + // 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. R=me Feel free to fixup comments and commit.
Jeremy Orlow
Comment 4 2010-01-28 23:15:43 PST
Committed r54046: <http://trac.webkit.org/changeset/54046>
Note You need to log in before you can comment on or make changes to this bug.