Expose the capturePicture feature in RenderView for Android WebView legacy API support.

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 83fc39483cc220ea8f8c5b77fbd4a409897821fa..d94f0b996377e97de89ae4b4d9b97e6feaab24db 100644
--- a/content/common/swapped_out_messages.cc
+++ b/content/common/swapped_out_messages.cc
@@ -36,7 +36,9 @@ bool SwappedOutMessages::CanSendWhileSwappedOut(const IPC::Message* msg) {
       break;
   }
 
-  return false;

[mkosiba (inactive), 2013/02/14 14:03:16]

I think it might be fine to simply say that replies to sync messages are always
allowed rather than adding yet another method to the content/ API.

I don't think such a change could 'hurt' the rest of Chromium since, IIRC,
outside of WebView, the channel would disallow a sync message anyway, right?

[Leandro Graciá Gil, 2013/02/14 14:25:14]

I think the question is if renderer -> browser synchronous IPC messages should
send back a reply to renderers being swapped out. If that's fine or we simply
don't care because other cases won't use a sync channel, then we probably want
to add IPC_REPLY_ID here rather than adding a new API.

Is there any other code in Chrome triggering browser -> renderer synchronous
IPCs? We do only for legacy WebView API compatibility.

+  // Check with the embedder as well.
+  ContentClient* client = GetContentClient();
+  return client->CanSendWhileSwappedOut(msg);
 }
 
 bool SwappedOutMessages::CanHandleWhileSwappedOut(