First experimental implementation of the Clear-Site-Data header

content/browser/frame_host/navigation_handle_impl.h

Index: content/browser/frame_host/navigation_handle_impl.h
diff --git a/content/browser/frame_host/navigation_handle_impl.h b/content/browser/frame_host/navigation_handle_impl.h
index 264bffa5289c14ca41f7bd867563bdfefd1c26a4..8d0df37bd8c4df56eb9da55c9290fd5055d78170 100644
--- a/content/browser/frame_host/navigation_handle_impl.h
+++ b/content/browser/frame_host/navigation_handle_impl.h
@@ -9,6 +9,8 @@
 
 #include <stddef.h>
 
+#include <memory>
+
 #include "base/callback.h"
 #include "base/macros.h"
 #include "base/memory/ref_counted.h"
@@ -25,6 +27,7 @@ struct FrameHostMsg_DidCommitProvisionalLoad_Params;
 
 namespace content {
 
+class ClearSiteDataHeaderObserver;
 class NavigatorDelegate;
 class ResourceRequestBodyImpl;
 
@@ -306,6 +309,9 @@ class CONTENT_EXPORT NavigationHandleImpl : public NavigationHandle {
   // 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_;