First experimental implementation of the Clear-Site-Data header

content/browser/frame_host/navigation_handle_impl.h

 // Copyright 2015 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.
 
 #ifndef CONTENT_BROWSER_FRAME_HOST_NAVIGATION_HANDLE_IMPL_H_
 #define CONTENT_BROWSER_FRAME_HOST_NAVIGATION_HANDLE_IMPL_H_
 
 #include "content/public/browser/navigation_handle.h"
 
 #include <stddef.h>
 
+#include <memory>
+
 #include "base/callback.h"
 #include "base/macros.h"
 #include "base/memory/ref_counted.h"
 #include "base/memory/scoped_vector.h"
 #include "content/browser/frame_host/frame_tree_node.h"
 #include "content/browser/frame_host/render_frame_host_impl.h"
 #include "content/common/content_export.h"
 #include "content/public/browser/navigation_data.h"
 #include "content/public/browser/navigation_throttle.h"
 #include "content/public/common/request_context_type.h"
 #include "url/gurl.h"
 
 struct FrameHostMsg_DidCommitProvisionalLoad_Params;
 
 namespace content {
 
+class ClearSiteDataHeaderObserver;
 class NavigatorDelegate;
 class ResourceRequestBodyImpl;
 
 // This class keeps track of a single navigation. It is created upon receipt of
 // a DidStartProvisionalLoad IPC in a RenderFrameHost. The RenderFrameHost owns
 // the newly created NavigationHandleImpl as long as the navigation is ongoing.
 // The NavigationHandleImpl in the RenderFrameHost will be reset when the
 // navigation stops, that is if one of the following events happen:
 //   - The RenderFrameHost receives a DidStartProvisionalLoad IPC for a new
 //   navigation (see below for special cases where the DidStartProvisionalLoad
@@ skipping 261 matching lines @@
   // Whether the navigation is in the middle of a transfer. Set to false when
   // the DidStartProvisionalLoad is received from the new renderer.
   bool is_transferring_;
 
   // The FrameTreeNode this navigation is happening in.
   FrameTreeNode* frame_tree_node_;
 
   // A list of Throttles registered for this navigation.
   ScopedVector<NavigationThrottle> throttles_;
 
+  // Handler of the experiment Clear-Site-Data header.
+  std::unique_ptr<ClearSiteDataHeaderObserver> clear_site_data_header_observer_;

[nasko, 2016/07/28 17:30:31]

This doesn't seem correct. WebContentsObservers should be 1:1 with WebContents
and WebContents is 1:many with NavigationHandle.

[msramek, 2016/08/01 16:03:19]

I agree that this is weird here. Let me summarize the history of this CL first.

The idea was that we might want the navigation to be blocked while deleting the
data, that's why we used NavigationThrottle. But we weren't sure yet (it's hard
to say without testing this out in the wild), and we think that the blocking
approach will require some UI to tell the user what's going on. That's why we
started with a NavigationThrottle. Now, Camille suggested to use a
WebContentsObserver instead since a) we don't need throttle if we're not
actually blocking the navigation yet, and b) we need to output console messages,
but NavigationThrottle::WillProcessResponse might not have the correct RFH yet.

So I changed NavigationThrottle to WebContentsObserver. But this is no longer a
good place to hook it up. Do you have any suggestion where to? This observer is
supposed to exist on every single WebContents, since it's the platform that
should recognize the Clear-Site-Data header, not a browser feature.

Alternatively, we can return to NavigationThrottle if we find a different way to
output console messages.

And actually, I should probably write all of this down to a doc.

[nasko, 2016/08/03 20:53:13]

Hmm, why do we need UI for this? It is part of the loading of a page that the
page requests the browser to do the data deletion. Exposing UI for this will
only lead to confusion, so IMHO it is ok to just proceed with this.

Furthermore, I think it will be a lot more consistent to defer the navigation
until the data is deleted and only allow it to commit once the data deletion is
complete. However, this is more of a design/spec question, so let's discuss
separately.
Sounds like a good suggestion :). If you don't need to defer/pause navigations,
WebContentsObserver is what you would want to have.
Why not instantiate it in the WebContentsImpl constructor? ;) There are already
observers as members in WebContentsImpl itself and you can add the new one
directly there.
Let's not do a NavigationThrottle, unless we really need to pause navigations to
do deletion.
Thanks for the doc.

[msramek, 2016/08/04 19:08:38]

Thanks a lot for your feedback in the doc, Nasko! I didn't have a chance to get
back to the CL today, but the way forward seems to be clear. It seems that by
now there's more support for synchronous deletion, so I'll talk to Mike again to
make a more binding decision. 

If we proceed with the synchronous one, I'll return to using a
NavigationThrottle and see if I can get RFH in the destructor.

If we proceed with the asynchronous, we'll stay with WebContentsObserver that
will be instantiated directly in WebContentsImpl.

+
   // The index of the next throttle to check.
   size_t next_index_;
 
   // The time this navigation started.
   const base::TimeTicks navigation_start_;
 
   // The unique id of the corresponding NavigationEntry.
   int pending_nav_entry_id_;
 
   // The fetch request context type.
   RequestContextType request_context_type_;
 
   // This callback will be run when all throttle checks have been performed.
   ThrottleChecksFinishedCallback complete_callback_;
 
   // Embedder data tied to this navigation.
   std::unique_ptr<NavigationData> navigation_data_;
 
   DISALLOW_COPY_AND_ASSIGN(NavigationHandleImpl);
 };
 
 }  // namespace content
 
 #endif  // CONTENT_BROWSER_FRAME_HOST_NAVIGATION_HANDLE_IMPL_H_