<webview>: Plumb edit commands

content/common/browser_plugin/browser_plugin_messages.h

Index: content/common/browser_plugin/browser_plugin_messages.h
diff --git a/content/common/browser_plugin/browser_plugin_messages.h b/content/common/browser_plugin/browser_plugin_messages.h
index 61c970d994a5530639754df1de2d9dfdaa31553f..8590ca24097506a63c161b1cce3c8db93206f9a7 100644
--- a/content/common/browser_plugin/browser_plugin_messages.h
+++ b/content/common/browser_plugin/browser_plugin_messages.h
@@ -15,6 +15,7 @@
 #include "content/common/browser_plugin/browser_plugin_message_enums.h"
 #include "content/common/content_export.h"
 #include "content/common/content_param_traits.h"
+#include "content/common/edit_command.h"
 #include "content/public/common/common_param_traits.h"
 #include "ipc/ipc_channel_handle.h"
 #include "ipc/ipc_message_macros.h"
@@ -152,6 +153,11 @@ IPC_MESSAGE_ROUTED2(BrowserPluginHostMsg_ExecuteEditCommand,
                      int /* instance_id */,
                      std::string /* command */)
 
+// This message must be sent just before sending a key event.
+IPC_MESSAGE_ROUTED2(BrowserPluginHostMsg_SetEditCommandsForNextKeyEvent,
+                    int /* instance_id */,
+                    std::vector<content::EditCommand> /* edit_commands */)

[Charlie Reis, 2013/05/28 16:49:25]

Sanity check: What damage could a compromised renderer do if it sent corrupted
EditCommands?  I see that we currently send them from the browser to the
renderer in input_messages.h, but the browser is trusted.  We wouldn't want a
bad renderer to take over the browser or another renderer by sending it a bad
EditCommand.

(If there's some validation logic or a reason this is safe, then I'm fine with
it.)

[Fady Samuel, 2013/05/28 21:24:17]

Edit commands are derived from key combinations. We already forward (and trust)
mouse events and touch events from the embedder to the guest. Why would edit
commands be any different?

Mind you, for keyboard events we actually grab those off the embedder's queue. I
did that for implementation simplicity and not necessarily for security:
NativeWebKeyboardEvents are required to process system keys if I recall
correctly. Thus, rather than creating a new WebKeyboardEvent for the guest from
the embedder, we grab the embedder's from its key queue.

Maybe we need to rethink the security of input events in general?

+
 // This message is sent to the browser process to enable or disable autosize
 // mode.
 IPC_MESSAGE_ROUTED3(