WebUIImpl currently handles WebContents events like RenderView{Created,Reused} and RenderProcessGone() in an ad-hoc or inconsistent (i.e. handler-specific) way.  It'd be better for WebUIImpl to implement the WebContentsObserver[1] API and all handlers act consistently when a renderer is created, reloads, or crashes.

Previous difficulties in switching WebUIImpl to a WebContentsObserver involved WebContentsObserver::web_contents() returning nullptr during destruction.  If we implemented

  WebContents* WebUIImpl::GetWebContents() {
    return web_contents();
  }

then we'd hit issues in handler destructors like this[2]:

  AppLauncherHandler::~AppLauncherHandler() {
    // This segfaults because it relies on web_ui()->GetWebContents()[3].
    ExtensionRegistry::Get(Profile::FromWebUI(web_ui()))->RemoveObserver(this);
  }

In this handler's case, we'd need to cache a reference to the owning Profile*.

There's probably many more issues we just haven't found yet ;).  I also considered trying to destroy WebUI objects earlier in the destruction cycle, before WebContentsObserver::web_contents() is nullptr.

[1] https://code.google.com/p/chromium/codesearch#chromium/src/content/public/browser/web_contents_observer.h&q=webcontentsobserver&sq=package:chromium&type=cs&l=48
[2] https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/webui/ntp/app_launcher_handler.cc&sq=package:chromium&type=cs&l=119&rcl=1462792609
[3] https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/profiles/profile.cc&q=Profile%20FromWebUI&sq=package:chromium&type=cs&l=57

Additional context: https://codereview.chromium.org/1315723003