Propagate inert state to OOPIFs when a modal dialog is active

content/browser/frame_host/render_widget_host_view_child_frame.cc

Index: content/browser/frame_host/render_widget_host_view_child_frame.cc
diff --git a/content/browser/frame_host/render_widget_host_view_child_frame.cc b/content/browser/frame_host/render_widget_host_view_child_frame.cc
index 59efca167892939fc60e02cc0a8925b1b11c5145..8920843d77fb378e236f9df7fc6970b7e28666c9 100644
--- a/content/browser/frame_host/render_widget_host_view_child_frame.cc
+++ b/content/browser/frame_host/render_widget_host_view_child_frame.cc
@@ -383,6 +383,11 @@ void RenderWidgetHostViewChildFrame::UpdateViewportIntersection(
                                                     viewport_intersection));
 }
 
+void RenderWidgetHostViewChildFrame::SetIsInert(bool inert) {
+  if (host_)
+    host_->Send(new ViewMsg_SetIsInert(host_->GetRoutingID(), inert));

[alexmos, 2017/06/16 02:17:57]

To me it seemed a little confusing to have the inert state come in with a frame
message, but then forward it with a view message, especially given that the
inert state is stored per-frame.  Wouldn't it work to just handle
FrameHostMsg_SetIsInert in RenderFrameProxyHost and send it to
frame_tree_node_->current_frame_host()? 

[kenrb, 2017/06/19 19:26:22]

Originally I did it this way to be consistent with how parent-child state
updates are generally done, which lets us keep handlers on RenderWidget for
messages that only go to local frame roots.

More concretely, your point elsewhere about frame navigations is potentially a
problem, and suggests that this is better as a ViewMsg. If the child frame does
a cross-process navigation, the inert bit needs to be re-sent, along with other
widget-level state. It would be difficult to do that with a FrameMsg, rather
than keeping the state in CPFC and sending it with other state from the
RenderWidgetHostView. The current patchset incorporates the latter approach.

[alexmos, 2017/06/20 18:46:09]

Would there still be a problem if we have a(b(b)), and the bottom child
navigates to c?  The IPC would only be sent to the middle child and cached on
its CPFC, and then when the bottom child navigates, how will it pull it in?

Given that we do need to cache this in the browser process, I'm also thinking
why we couldn't use FrameReplicationState, which also stores the replicated bits
on FTN so we can send them in cases like this.  I guess the differences here are
(1) this is about input events, which, as you note, as generally handled on a
per-widget level, and (2) proxies don't need to know inertness -- right?

[kenrb, 2017/06/22 15:33:35]

When the bottom child swaps, the newly created RemoteFrame sends the inert state
to the renderer.
When I started working on this I had considered FrameReplicationState, but
thought this was a better approach for the reasons you mention. In general it
seems like the parent-child state message should be in this path, whereas
generic state replication should use FrameReplicationState.

[alexmos, 2017/06/22 17:09:27]

Acknowledged.

+}
+
 void RenderWidgetHostViewChildFrame::GestureEventAck(
     const blink::WebGestureEvent& event,
     InputEventAckState ack_result) {