Implements JS bindings for mojo shared buffer.

third_party/WebKit/Source/core/mojo/MojoCloneBufferHandleFlags.idl

Index: third_party/WebKit/Source/core/mojo/MojoCloneBufferHandleFlags.idl
diff --git a/third_party/WebKit/Source/core/mojo/MojoCloneBufferHandleFlags.idl b/third_party/WebKit/Source/core/mojo/MojoCloneBufferHandleFlags.idl
new file mode 100644
index 0000000000000000000000000000000000000000..902275154ff30cbdb6d46a7979caaecb2333c7fb
--- /dev/null
+++ b/third_party/WebKit/Source/core/mojo/MojoCloneBufferHandleFlags.idl
@@ -0,0 +1,7 @@
+// Copyright 2017 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.
+
+dictionary MojoCloneBufferHandleFlags {
+  boolean readOnly = false;

[jbroman, 2017/03/01 23:29:37]

I'd missed the first time through that these can be read-only. Since we don't
have any support for a "read-only" array buffer, the resulting ArrayBuffer (and
any views into it) will still seem writable. I assume we'll get a renderer crash
(due to memory access violation) if script ever does write it.

mojo/edk/js/ already has this issue, so I assume you're aware of/okay with it.
(Naturally this means that any script that has access to a mapped buffer must be
extremely careful.)

[yzshen1, 2017/03/01 23:33:08]

Alok and I chatted about this. Because at the moment only some special contexts
have access to the Mojo APIs (WebUI, layout tests, etc), it should be okay. In
the future if we want to expose this to arbitrary web pages, we will need to
carefully evaluate its security implication, I think.

+};