Reland #1 of: Move WebUI ownership from the RenderFrameHostManager to the RenderFrameHost.

content/browser/frame_host/render_frame_host_impl.h

Index: content/browser/frame_host/render_frame_host_impl.h
diff --git a/content/browser/frame_host/render_frame_host_impl.h b/content/browser/frame_host/render_frame_host_impl.h
index cbefae850313ac59da8225e933c4c9706532dd2d..9bb82927172259b2e41b9b31cfefce97c70a8de8 100644
--- a/content/browser/frame_host/render_frame_host_impl.h
+++ b/content/browser/frame_host/render_frame_host_impl.h
@@ -17,6 +17,7 @@
 #include "content/browser/accessibility/browser_accessibility_manager.h"
 #include "content/browser/bad_message.h"
 #include "content/browser/site_instance_impl.h"
+#include "content/browser/webui/web_ui_impl.h"
 #include "content/common/accessibility_mode_enums.h"
 #include "content/common/ax_content_node_data.h"
 #include "content/common/content_export.h"
@@ -218,6 +219,14 @@ class CONTENT_EXPORT RenderFrameHostImpl
   RenderFrameHostDelegate* delegate() { return delegate_; }
   FrameTreeNode* frame_tree_node() { return frame_tree_node_; }
 
+  // Returns the associated WebUI or null if none applies.
+  WebUIImpl* web_ui() const { return web_ui_.get(); }
+
+  // Returns the pending WebUI, or null if none applies.
+  WebUIImpl* pending_web_ui() const {
+    return should_reuse_web_ui_ ? web_ui_.get() : pending_web_ui_.get();
+  }
+
   // Returns this RenderFrameHost's loading state. This method is only used by
   // FrameTreeNode. The proper way to check whether a frame is loading is to
   // call FrameTreeNode::IsLoading.
@@ -478,6 +487,26 @@ class CONTENT_EXPORT RenderFrameHostImpl
   // addition, its associated RenderWidgetHost has to be focused.
   bool IsFocused();
 
+  // Updates the pending WebUI of this RenderFrameHost based on the provided
+  // |dest_url|, setting it to either none, a new instance or to reuse the
+  // currently active one. Returns true if the pending WebUI was updated.
+  // If this is a history navigation its NavigationEntry bindings should be
+  // provided through |entry_bindings| to allow verifying that they are not
+  // being set differently this time around. Otherwise |entry_bindings| should
+  // be set to NavigationEntryImpl::kInvalidBindings so that no checks are done.
+  bool UpdatePendingWebUI(const GURL& dest_url, int entry_bindings);
+
+  // Updates the active WebUI with the pending one set by the last call to
+  // UpdatePendingWebUI and then clears any pending data. If UpdatePendingWebUI
+  // was not called the active WebUI will simply be cleared.
+  void CommitPendingWebUI();
+
+  // Destroys the pending WebUI and resets related data.
+  void ClearPendingWebUI();
+
+  // Destroys all WebUI instances and resets related data.
+  void ClearAllWebUIs();

[nasko, 2015/11/18 23:48:03]

nit: drop the "s" at the end of the method name.

[carlosk, 2015/11/19 16:49:14]

Done.

Is there a rule-of-thumb here? It seemed to make sense to use a plural form...

+
   // Returns the Mojo ImageDownloader service.
   const image_downloader::ImageDownloaderPtr& GetMojoImageDownloader();
 
@@ -825,6 +854,21 @@ class CONTENT_EXPORT RenderFrameHostImpl
   // NavigationHandle for it is owned by the NavigationRequest.
   scoped_ptr<NavigationHandleImpl> navigation_handle_;
 
+  // The associated WebUIImpl and its type. They will be set if the current
+  // document is from WebUI source. Otherwise they will be null and
+  // WebUI::kNoWebUI, respectively.
+  scoped_ptr<WebUIImpl> web_ui_;
+  WebUI::TypeID web_ui_type_;
+
+  // The pending WebUIImpl and its type. These will only be set during a
+  // same-site navigation to a document requiring a new WebUI.

[nasko, 2015/11/18 23:48:03]

Why do we need a pending WebUI for a same-site navigation? It makes sense to
have it for none->WebUI needed one.

[carlosk, 2015/11/19 16:49:14]

This is the main motivation of this revert to having the pending WebUI. It is
used exclusively for same-site navigations, when the RFH is reused, and there is
a WebUI transition. As shown by the many cases of triggered CHECKs when I landed
the original change, this is still happening.

In any cross-site navigation the pending WebUI is not used (more precisely, it
is used momentarily only to update the active one).

I also updated this comment because the word "set" was a tad misleading. These
values being null/kNoWebUI are also a case of "usage" when transitioning from
having to not having a WebUI.

[nasko, 2015/11/19 19:45:24]

Transition from having a WebUI to not having WebUI should be a cross-process
navigation.

[carlosk, 2015/11/20 12:21:10]

It should indeed and that's what we expected when the 1st CL landed. See
http://crbug.com/557116#c1 (restricted) for links to crash reports of when it
wasn't .

+  scoped_ptr<WebUIImpl> pending_web_ui_;
+  WebUI::TypeID pending_web_ui_type_;
+
+  // If true the associated WebUI should be reused when CommitPendingWebUI is
+  // called (no pending instance should be set).
+  bool should_reuse_web_ui_;
+
   // NOTE: This must be the last member.
   base::WeakPtrFactory<RenderFrameHostImpl> weak_ptr_factory_;