Expose v8 context a MessagePort lives in to give content side code a valid context to (de)serialize…

Source/core/dom/MessagePort.cpp

Index: Source/core/dom/MessagePort.cpp
diff --git a/Source/core/dom/MessagePort.cpp b/Source/core/dom/MessagePort.cpp
index d9da4a2e26a76e97ed76ca6076dc57a389cf9513..392bc0dddf6005013937b30954a1e58de8ecf778 100644
--- a/Source/core/dom/MessagePort.cpp
+++ b/Source/core/dom/MessagePort.cpp
@@ -31,6 +31,7 @@
 #include "bindings/core/v8/ExceptionStatePlaceholder.h"
 #include "bindings/core/v8/SerializedScriptValue.h"
 #include "bindings/core/v8/SerializedScriptValueFactory.h"
+#include "bindings/core/v8/V8AbstractEventListener.h"
 #include "core/dom/CrossThreadTask.h"
 #include "core/dom/ExceptionCode.h"
 #include "core/dom/ExecutionContext.h"
@@ -266,4 +267,25 @@ void MessagePort::trace(Visitor* visitor)
     EventTargetWithInlineData::trace(visitor);
 }
 
+v8::Isolate* MessagePort::scriptIsolate()
+{
+    ASSERT(executionContext());
+    return toIsolate(executionContext());
+}
+
+v8::Handle<v8::Context> MessagePort::scriptContext()
+{
+    ASSERT(executionContext());
+    // Since a MessagePort doesn't live in any particular world, return the
+    // context for some arbitrary event listener that is registered with this
+    // port.

[haraken, 2015/02/25 07:44:34]

I don't understand why this is right. Not all event listeners attached to the
MessagePort have the same world. Why is it a right thing to use a world of an
arbitrary event listener?

Remember that serialize/deserialize can execute any arbitrary JavaScript, so it
is important to use a correct context.

[Marijn Kruisselbrink, 2015/02/25 17:35:17]

The context returned by this is used by WebMessagePortChannelImpl to convert
some message from a base::Value to a serialized script value. On one hand you
could say that there is no existing context/world that would be suitable for
this, since this conversion/serialization is theoretically observable by
javascript code living in whatever world/context is used. And I agree with that,
which is why all this is only a temporary hack, to get something working, and to
be able to experiment (and have others experiment) and find out if this
MessagePort to talk with native code thing is really something that is going to
be as useful as we hope it is. But no matter the outcome of this experiment,
this MessagePort::scriptContext method is not going to stick around. If we
decide we want MessagePort<->native code communication, I will work on being
able to do this without the extra serialize/deserialize steps. But doing the
fairly invasive refactoring required for that now, while it's not entirely clear
this is actually useful, would seem like a bad idea, when a "good enough" (to
experiment) solution is possible with little change to blink code.

And to answer our actual question why I think it is "good enough" to use the
world of an arbitrary event listener: whatever world is picked here is going to
deserialize the message anyway, that's why it is an event listener. It doesn't
seem like there is that much more of a security risk by using the same
world/context first to also serialize that same message.

+    const EventListenerVector& listeners = getEventListeners(EventTypeNames::message);
+    for (const RegisteredEventListener& listener: listeners) {
+        const V8AbstractEventListener* v8listener = V8AbstractEventListener::cast(listener.listener.get());
+        if (v8listener)
+            return toV8Context(executionContext(), v8listener->world());
+    }
+    return v8::Handle<v8::Context>();
+}
+
 } // namespace blink