Make rendering timeouts work even if paint data received early

content/browser/renderer_host/render_widget_host_impl.h

Index: content/browser/renderer_host/render_widget_host_impl.h
diff --git a/content/browser/renderer_host/render_widget_host_impl.h b/content/browser/renderer_host/render_widget_host_impl.h
index 17e3e82bff430ca29fc5826587cb998ecfb9a050..c03935a82fa3e5a1264efd131836ce7eb92c8a3f 100644
--- a/content/browser/renderer_host/render_widget_host_impl.h
+++ b/content/browser/renderer_host/render_widget_host_impl.h
@@ -267,6 +267,10 @@ class CONTENT_EXPORT RenderWidgetHostImpl
   // graphics.
   void StopNewContentRenderingTimeout();
 
+  // Notification that a new compositor frame has been generated following
+  // a page load. This stops |new_content_rendering_timeout_|.

[Charlie Reis, 2015/09/30 20:36:19]

nit: "...or prevents the timer from running if it hasn't started yet."

[kenrb, 2015/09/30 21:25:02]

Done.

+  void OnFirstPaintAfterLoad();

[Charlie Reis, 2015/09/30 20:36:19]

Are we guaranteed to always get both this and the commit IPC before seeing any
other instances?

For example, I don't want to accidentally allow this:
1) OnFirstPaintAfterLoad for page 1.
(No commit of page 1 for some reason)
2) OnDidCommitProvisionalLoad for page 2.
(No timer starts because of #1, but page 2 can now be spoofed.)

[kenrb, 2015/09/30 21:25:02]

It shouldn't be possible to get a ViewHostMsg_DidFirstPaintAfterLoad without a
FrameHostMsg_DidCommitProvisionalLoad. Both are triggered in the renderer by
FrameLoaderClientImpl::dispatchDidCommitLoad. The only bailout I see is that
FrameHostMsg_DidCommitProvisionalLoad won't be sent if the WebFrame has no
client (i.e. no RenderFrameImpl). In this case I imagine the frame has been
destroyed so we don't have to worry about any spoofing problems, but I would be
interested if Daniel can think of a way that could cause a problem.

It's tricky to reason through this, but does that guarantee we won't run into
problems? I would assume that if the load commit for page 1 is sent, that it
isn't possible for a load commit for page 2 to arrive before it (this would seem
really bad).

+
   // Forwards the given message to the renderer. These are called by the view
   // when it has received a message.
   void ForwardGestureEventWithLatencyInfo(
@@ -810,6 +814,7 @@ class CONTENT_EXPORT RenderWidgetHostImpl
   scoped_ptr<TimeoutMonitor> hang_monitor_timeout_;
 
   scoped_ptr<TimeoutMonitor> new_content_rendering_timeout_;
+  bool received_paint_after_load_;

[Charlie Reis, 2015/09/30 20:36:19]

Let's say when we expect this to be true, since it's not clear.  I think it's
exactly the time interval between the first paint and the navigation commit, if
they happen in that order.  It's never true if the commit happens first, and
(hopefully?) we're guaranteed to always receive those IPCs in pairs without
other messages from other navigations interleaved.

[kenrb, 2015/09/30 21:25:02]

Done.

 
 #if defined(OS_WIN)
   std::list<HWND> dummy_windows_for_activation_;