Implement BroadcastChannel

third_party/WebKit/Source/modules/broadcastchannel/BroadcastChannelConnection.cpp

Index: third_party/WebKit/Source/modules/broadcastchannel/BroadcastChannelConnection.cpp
diff --git a/third_party/WebKit/Source/modules/broadcastchannel/BroadcastChannelConnection.cpp b/third_party/WebKit/Source/modules/broadcastchannel/BroadcastChannelConnection.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..5d60e99c34bff7dfeee63b06dbc5dcb219ae50e3
--- /dev/null
+++ b/third_party/WebKit/Source/modules/broadcastchannel/BroadcastChannelConnection.cpp
@@ -0,0 +1,120 @@
+// Copyright 2016 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.
+
+#include "modules/broadcastchannel/BroadcastChannelConnection.h"
+
+#include "platform/ThreadSafeFunctional.h"
+#include "platform/mojo/MojoHelper.h"
+#include "public/platform/Platform.h"
+#include "public/platform/ServiceRegistry.h"
+#include "public/platform/WebTaskRunner.h"
+#include "public/platform/WebTraceLocation.h"
+
+namespace blink {
+
+namespace {
+
+void connectToService(webmessaging::mojom::blink::BroadcastChannelServiceRequest request)
+{
+    DCHECK(Platform::current()->mainThread()->isCurrentThread());
+    Platform::current()->serviceRegistry()->connectToRemoteService(std::move(request));
+}
+
+webmessaging::mojom::blink::BroadcastChannelServicePtr& getThreadSpecificService()
+{
+    DEFINE_THREAD_SAFE_STATIC_LOCAL(ThreadSpecific<webmessaging::mojom::blink::BroadcastChannelServicePtr>, service, new ThreadSpecific<webmessaging::mojom::blink::BroadcastChannelServicePtr>);

[esprehn, 2016/06/06 02:29:42]

Hmm why do we need statics for this? I don't think we want to be adding statics
for services. Why can't frames or pages keep the connection?

[Marijn Kruisselbrink, 2016/06/06 20:05:29]

Because in mojo every interface is its own pipe without any ordering guarantees
I do need to use the same mojo connection for all channels that share the same
"responsible event loop" (step 8 in
https://html.spec.whatwg.org/multipage/comms.html#dom-broadcastchannel-postme...
requires me to sort all BCChannel instances with the same event loop in creation
order). For workers that's no problem, and it would be possible to somehow
attach the mojo connection to the worker, but for frames/pages there can be at
most one event loop for any "unit of related browsing contexts". I suppose that
I could use the "top-most" context as representative of this unit of related
browsing contexts, but it seemed simpler to just do this as a thread-local thing
instead. In particular as windows can disown themselves (by writing to
self.opener), getting that right becomes very tricky.

I could go back to something more like PS4, which doesn't have most of the
bookkeeping in the renderer (but still has this particular threadspecific static
service connection). Downside of that is that the mojo API is (in my opinion)
more confusing, and it's of course also less efficient when a thread has more
than one connection to the same channel (as all messages to/from that thread
will then end up being send multiple times over IPC). I still do like the
simplicity of PS4 though, but I also like the benefits of having this extra
bookkeeping in the renderer (even though the performance is probably not going
to matter much for what I imagine this would be used for).

[haraken, 2016/06/07 00:53:26]

OK. Another option would be to use Page for the main thread and use
WorkerGlobalScope for workers, but it would be nastier than this CL.

The underlying issue would be that Blink doesn't have a good class that
abstracts the "top-level" browsing context.

[Marijn Kruisselbrink, 2016/06/07 01:18:39]

Yeah, anything more contained than a service connection per thread seems like it
would be more effort/complication than it's worth.
And even with such a thing, code would still have to be really careful that such
a concept would be used in the expected way, especially in cases where documents
can disown themselves, thus possibly changing their top-level browsing context
(depending on how that would be defined).

+    if (!service.isSet()) {
+        Platform::current()->mainThread()->getWebTaskRunner()->postTask(BLINK_FROM_HERE,
+            threadSafeBind(&connectToService, passed(mojo::GetProxy(&*service))));
+    }
+    return *service;
+}
+
+// BroadcastChannelConnection instances are jointly owned by the clients using
+// the connection. This map is merely a way for new clients to lookup the
+// connection to use, hence it stores weak references to connections.
+using ConnectionKey = std::pair<RefPtr<SecurityOrigin>, String>;
+using ConnectionMap = HeapHashMap<ConnectionKey, WeakMember<BroadcastChannelConnection>>;
+
+ConnectionMap* getConnectionMap()
+{
+    DEFINE_THREAD_SAFE_STATIC_LOCAL(ThreadSpecific<Persistent<ConnectionMap>>, connectionMap, new ThreadSpecific<Persistent<ConnectionMap>>);

[haraken, 2016/06/06 02:05:47]

+sigbjornf@: Please check if this usage is correct :)

[sof, 2016/06/06 06:35:45]

Usage is exemplary; we don't try to hide very many details surrounding
ThreadSpecific<> persistent singleton initialization yet.

+    if (!connectionMap.isSet()) {
+        *connectionMap = new ConnectionMap;
+        connectionMap->registerAsStaticReference();
+    }
+    return *connectionMap;
+}
+
+} // namespace
+
+// static
+BroadcastChannelConnection* BroadcastChannelConnection::getForChannel(const RefPtr<SecurityOrigin>& origin, const String& name)
+{
+    ConnectionMap* connectionMap = getConnectionMap();
+    auto it = connectionMap->find(ConnectionKey(origin, name));
+    if (it != connectionMap->end())
+        return it->value;
+
+    webmessaging::mojom::blink::BroadcastChannelServicePtr& service = getThreadSpecificService();
+    webmessaging::mojom::blink::BroadcastChannelClientAssociatedPtrInfo localClientInfo;
+    BroadcastChannelConnection* connection = new BroadcastChannelConnection(name, origin, &localClientInfo, service.associated_group());
+    service->Subscribe(origin, name, std::move(localClientInfo));
+    return connection;
+}
+
+BroadcastChannelConnection::~BroadcastChannelConnection()
+{
+}
+
+void BroadcastChannelConnection::registerClient(Client* client)
+{
+    m_clients.add(client);
+}
+
+void BroadcastChannelConnection::unregisterClient(Client* client)
+{
+    m_clients.remove(client);
+}
+
+void BroadcastChannelConnection::broadcast(Client* from, const String& message)
+{
+    for (Client* client : m_clients) {
+        if (client != from)
+            client->onMessage(message);
+    }
+    getThreadSpecificService()->Broadcast(from->origin(), from->name(), message);
+}
+
+DEFINE_TRACE(BroadcastChannelConnection)
+{
+    visitor->trace(m_clients);
+}
+
+BroadcastChannelConnection::BroadcastChannelConnection(const String& name, const RefPtr<SecurityOrigin>& origin, webmessaging::mojom::blink::BroadcastChannelClientAssociatedPtrInfo* clientInfo, mojo::AssociatedGroup* associatedGroup)
+    : m_name(name)
+    , m_origin(origin)
+    , m_binding(this, clientInfo, associatedGroup)
+{
+    m_binding.set_connection_error_handler(createBaseCallback(bind(&BroadcastChannelConnection::onError, WeakPersistentThisPointer<BroadcastChannelConnection>(this))));

[haraken, 2016/06/06 02:05:47]

+hiroshige@: Is this a correct usage to bind a Blink function with mojo?

[Marijn Kruisselbrink, 2016/06/06 20:05:29]

fwiw this is how at least PaymentRequest does it
(https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/paymen...)

It does seem somewhat fragile though that the WeakPersistentThisPointer is
necessary to avoid having a memory leak because oilpan can't detect the
BroadcastChannelConnection->m_binding->error
callback->BroadcastChannelConnection cycle...

+    auto result = getConnectionMap()->set(ConnectionKey(m_origin, m_name), this);
+    DCHECK(result.isNewEntry) << "There should only be one connection per channel per thread.";
+    ALLOW_UNUSED_LOCAL(result);

[haraken, 2016/06/06 02:05:47]

Nit: Is this needed?

[Marijn Kruisselbrink, 2016/06/06 20:05:29]

Not sure. Assertions.h seems to suggest so though by suggesting that
DCHECK+ALLOW_UNUSED_LOCAL is the correct replacement for ASSERT_UNUSED.

+}
+
+void BroadcastChannelConnection::OnMessage(const String& message)
+{
+    for (Client* client : m_clients)
+        client->onMessage(message);
+}
+
+void BroadcastChannelConnection::onError()
+{
+    for (Client* client : m_clients)
+        client->onError();
+    m_clients.clear();
+    getConnectionMap()->remove(ConnectionKey(m_origin, m_name));
+}
+
+} // namespace blink