RenderWidget/RenderView: encapsulate ViewHostMsg_Show, etc, in a callback

content/common/swapped_out_messages.cc

Index: content/common/swapped_out_messages.cc
diff --git a/content/common/swapped_out_messages.cc b/content/common/swapped_out_messages.cc
index 776b8ee5c09b5af2f0eae23c78856f75da394404..3a47eda67ecc770ab401f55d444296535f94536c 100644
--- a/content/common/swapped_out_messages.cc
+++ b/content/common/swapped_out_messages.cc
@@ -27,6 +27,9 @@ bool SwappedOutMessages::CanSendWhileSwappedOut(const IPC::Message* msg) {
     case ViewHostMsg_Focus::ID:
     // Handled by RenderViewHost.
     case ViewHostMsg_ClosePage_ACK::ID:
+    case ViewHostMsg_ShowFullscreenWidget::ID:
+    case ViewHostMsg_ShowView::ID:
+    case ViewHostMsg_ShowWidget::ID:
     case ViewHostMsg_SwapCompositorFrame::ID:
     // Handled by SharedWorkerMessageFilter.
     case ViewHostMsg_DocumentDetached::ID:
@@ -68,12 +71,6 @@ bool SwappedOutMessages::CanHandleWhileSwappedOut(
   // Note that synchronous messages that are not handled will receive an
   // error reply instead, to avoid leaving the renderer in a stuck state.
   switch (msg.type()) {
-    // Sends an ACK.
-    case ViewHostMsg_ShowView::ID:
-    // Sends an ACK.
-    case ViewHostMsg_ShowWidget::ID:
-    // Sends an ACK.
-    case ViewHostMsg_ShowFullscreenWidget::ID:

[dcheng, 2016/11/21 11:19:52]

Out of curiosity, why did we move these?

I guess I would have expected the set of can send and can handle messages to
always be in sync, and I'm a bit surprised that that's not true.

[ncarter (slow), 2016/11/21 19:51:24]

I didn't change when these messages were sent, but I did change the IPC::Sender
via which they were sent -- they used to be sent via the RenderWidget targeting
a cached value of the view's route_id. When I moved them to the RenderView, it
broke window.open from oopifs and this was the fix.

I agree with you that CanHandle but not CanSend is a weird convention. Here is
what I previously assumed: that it was plausible in the ACK-required case, where
the RFH swaps out but still wants to ACK messages sent by the RF's RenderView
that were sent prior to the RF before the RF knew it was swapped out.

However, looking at the code, the CanHandleWhileSwappedOut restriction seems to
start being applied only after after the SwapOut_ACK arrives in the RFH, so this
isn't plausible. In other words, I think you're right.

So we probably ought to combine these two cases. I also strongly suspect that
the FrameHostMsg's are totally unnecessary in this list here, since we don't
seem to actually apply this filter for the RFH's OnMessageReceived, nor does the
RenderFrame's Send doesn't go through the RenderView. I'll try to clean it all
up in a subsequent patch.

     // Updates the previous navigation entry.
     case ViewHostMsg_UpdateState::ID:
     // Sends an ACK.