[Android] Add messages for Gin Java Bridge implementation

content/common/gin_java_bridge_messages.h

+// Copyright (c) 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.
+
+// IPC messages for injected Java objects (Gin-based implementation).
+
+// Multiply-included message file, hence no include guard.
+
+#include "base/basictypes.h"
+#include "content/common/content_export.h"
+#include "ipc/ipc_message_macros.h"
+
+#undef IPC_MESSAGE_EXPORT
+#define IPC_MESSAGE_EXPORT CONTENT_EXPORT
+#define IPC_MESSAGE_START GinJavaBridgeMsgStart
+
+// Messages for handling Java objects injected into JavaScript -----------------
+
+// Sent from browser to renderer to add a Java object with the given name.
+// Object IDs are generated on the browser side.
+IPC_MESSAGE_ROUTED2(GinJavaBridgeMsg_AddNamedObject,
+                    std::string /* name */,
+                    int32 /* object_id */)
+
+// Sent from browser to renderer to remove a Java object with the given name.

[palmer, 2014/04/25 22:37:06]

This should be merely advisory, for the benefit of the renderer, right?

The actual security/correctness comes from the fact that the browser will not
honor future requests to use this object?

[mnaganov (inactive), 2014/04/28 11:38:43]

Yes, that's correct.

+IPC_MESSAGE_ROUTED1(GinJavaBridgeMsg_RemoveNamedObject,
+                    std::string /* name */)
+
+// Sent from browser to renderer to control enumerability of methods exposed

[palmer, 2014/04/25 22:37:06]

Does this mean we trust the renderer to not expose non-enumerable methods? That
doesn't sound secure/correct.

[mnaganov (inactive), 2014/04/28 11:38:43]

OK, I will make renderers to query for method names each time they need them.
Then, if inspection has never been enabled, the renderer will never have a
complete list of methods (more exactly, it will not be able to find out, whether
it actually knows all the method names).

+// by injected objects.
+IPC_MESSAGE_ROUTED1(GinJavaBridgeMsg_SetAllowObjectContentsInspection,
+                    bool /* allow */)
+
+// Sent from renderer to browser to get information about methods of
+// the given object.
+IPC_SYNC_MESSAGE_ROUTED1_1(GinJavaBridgeHostMsg_GetMethods,
+                           int32 /* object_id */,
+                           std::set<std::string> /* returned_method_names */)
+
+// Sent from renderer to browser to invoke a method. Method arguments
+// are chained into |arguments| list. base::ListValue is used for |result| as
+// a container to work around immutability of base::Value.
+// Empty result list indicates that an error has happened on the Java side
+// (either bridge-induced error or an unhandled Java exception) and an exception
+// must be thrown into JavaScript.
+// Some special value types that are not supported by base::Value are encoded
+// as BinaryValues via GinJavaBridgeValue.
+IPC_SYNC_MESSAGE_ROUTED3_1(GinJavaBridgeHostMsg_InvokeMethod,
+                           int32 /* object_id */,
+                           std::string /* method_name */,
+                           base::ListValue /* arguments */,
+                           base::ListValue /* result */)
+
+// Sent from renderer to browser to inform that the JS wrapper of the object has
+// been completely dereferenced and garbage-collected.  Also used in a situation
+// when wrapper creation has failed.  The browser side, assumes
+// optimistically that every time an object is returned from a method, a
+// corresponding wrapper will be successfully created on the renderer side.

[palmer, 2014/04/25 22:37:06]

What happens if the optimistic assumption does not hold?

[mnaganov (inactive), 2014/04/28 11:38:43]

Then the renderer sends this message. I'll try to rephrase the doc to make this
more clear.

+IPC_MESSAGE_ROUTED1(GinJavaBridgeHostMsg_ObjectWrapperDeleted,
+                    int32 /* object_id */)