DOMStorageContextImpl that's implemented in terms of the new dom_storage classes.

content/browser/renderer_host/render_message_filter.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/browser/renderer_host/render_message_filter.h"
 
 #include <map>
 
 #include "base/bind.h"
 #include "base/bind_helpers.h"
@@ skipping 393 matching lines @@
     int64* cloned_session_storage_namespace_id) {
   if (!content::GetContentClient()->browser()->CanCreateWindow(
           GURL(params.opener_url), GURL(params.opener_security_origin),
           params.window_container_type, resource_context_,
           render_process_id_)) {
     *route_id = MSG_ROUTING_NONE;
     *surface_id = 0;
     return;
   }
 
+#ifdef ENABLE_NEW_DOM_STORAGE_BACKEND
+  // TODO(michaeln): Fix this.
+  // This is a bug in the existing impl, session storage is effectively
+  // leaked when created thru this code path (window.open()) since there
+  // is no balancing DeleteSessionStorage() for this Clone() call anywhere
+  // in the codebase. I'm replicating the bug for now.
+  *cloned_session_storage_namespace_id =
+      dom_storage_context_->LeakyCloneSessionStorage(
+          params.session_storage_namespace_id);
+#else
   *cloned_session_storage_namespace_id =
       dom_storage_context_->CloneSessionStorage(
           params.session_storage_namespace_id);
+#endif
+
   render_widget_helper_->CreateNewWindow(params,
                                          peer_handle(),
                                          route_id,
                                          surface_id);
 }
 
 void RenderMessageFilter::OnMsgCreateWidget(int opener_id,
                                             WebKit::WebPopupType popup_type,
                                             int* route_id,
                                             int* surface_id) {
@@ skipping 497 matching lines @@
   // for a resize or if no backing store) the RenderWidgetHost is blocking the
   // UI thread for some time, waiting for an UpdateRect from the renderer. If we
   // are going to switch to accelerated compositing, the GPU process may need
   // round-trips to the UI thread before finishing the frame, causing deadlocks
   // if we delay the UpdateRect until we receive the OnSwapBuffersComplete. So
   // the renderer sent us this message, so that we can unblock the UI thread.
   // We will simply re-use the UpdateRect unblock mechanism, just with a
   // different message.
   render_widget_helper_->DidReceiveUpdateMsg(msg);
 }