Port WebSockets to Mojo IPC

content/renderer/render_frame_impl.cc

Index: content/renderer/render_frame_impl.cc
diff --git a/content/renderer/render_frame_impl.cc b/content/renderer/render_frame_impl.cc
index c73b789cb8f00d00a90ce6b3407b47fca487437e..3edc9ddc42816ca213f33cc426a00989a56c4d9a 100644
--- a/content/renderer/render_frame_impl.cc
+++ b/content/renderer/render_frame_impl.cc
@@ -4263,8 +4263,7 @@ void RenderFrameImpl::requestStorageQuota(
 }
 
 void RenderFrameImpl::willOpenWebSocket(blink::WebSocketHandle* handle) {
-  WebSocketBridge* impl = static_cast<WebSocketBridge*>(handle);
-  impl->set_render_frame_id(routing_id_);
+  static_cast<WebSocketBridge*>(handle)->Initialize(GetServiceRegistry());

[Ben Goodger (Google), 2016/07/01 21:19:51]

Do you have an opinion about whether it'd be better to pass the registry in
here, or the WebSocketPtr?

It's a bit murky for the frame registry.. but for shell::Connection registries
I've been trying to avoid passing the connection/connectors around into feature
code since any GetInterface() call will have to be understood by the embedder &
reflected in its manifest. In practice this is not an issue for content today,
but may be eventually.

[darin (slow to review), 2016/07/06 16:57:21]

Good question. I'm not sure what is better.

 
One thing that is nice about passing the InterfaceProvider into the
WebSocketBridge is that it allows the details of how a WebSocket is acquired to
be contained in the WebSocketBridge code. The consumer of the WebSocketBridge
doesn't have to know those details. Admittedly, this is a fairly trivial example
as that isn't a complicated detail. It may be more interesting in other cases
though?

 }
 
 blink::WebPresentationClient* RenderFrameImpl::presentationClient() {