Propagate inert state to OOPIFs when a modal dialog is active

content/browser/frame_host/render_widget_host_view_child_frame.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/browser/frame_host/render_widget_host_view_child_frame.h"
 
 #include <algorithm>
 #include <utility>
 #include <vector>
 
@@ skipping 365 matching lines @@
   }
 }
 
 void RenderWidgetHostViewChildFrame::UpdateViewportIntersection(
     const gfx::Rect& viewport_intersection) {
   if (host_)
     host_->Send(new ViewMsg_SetViewportIntersection(host_->GetRoutingID(),
                                                     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) {
   bool not_consumed = ack_result == INPUT_EVENT_ACK_STATE_NOT_CONSUMED ||
                       ack_result == INPUT_EVENT_ACK_STATE_NO_CONSUMER_EXISTS;
   // GestureScrollBegin is consumed by the target frame and not forwarded,
   // because we don't know whether we will need to bubble scroll until we
   // receive a GestureScrollUpdate ACK. GestureScrollUpdate with unused
   // scroll extent is forwarded for bubbling, while GestureScrollEnd is
   // always forwarded and handled according to current scroll state in the
@@ skipping 448 matching lines @@
     auto origin = GetViewBounds().origin() -
                   frame_connector_->GetRootRenderWidgetHostView()
                       ->GetViewBounds()
                       .origin();
     return gfx::Point(origin.x(), origin.y());
   }
   return gfx::Point();
 }
 
 }  // namespace content