Plumbing from WebPresentationClient to the Presentation Mojo service for

content/renderer/presentation/presentation_dispatcher.cc

+// Copyright 2015 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 "content/renderer/presentation/presentation_dispatcher.h"
+
+#include "content/common/presentation/presentation_service.mojom.h"
+#include "content/public/common/service_registry.h"
+#include "content/public/renderer/render_frame.h"
+#include "third_party/WebKit/public/platform/WebPresentationController.h"
+
+namespace content {
+
+PresentationDispatcher::PresentationDispatcher(RenderFrame* render_frame)
+    : RenderFrameObserver(render_frame) {}
+
+PresentationDispatcher::~PresentationDispatcher() {}

[mark a. foltz, 2015/01/27 21:56:09]

Is it okay to drop the ptr to presentation_service_ on the floor?  If the
service isn't counting how many clients are holding ptrs, how do we know when to
destroy it safely?

[whywhat, 2015/01/28 01:52:37]

presentation_service_ is a smart pointer (mojo::InterfacePtr). I assume it takes
care of these things.

I thought about updating the WebPresentationController that the client became
null.

+
+void PresentationDispatcher::setController(
+    blink::WebPresentationController* controller) {
+  // Provide the service with the callback to get the next |availablechange|

[mark a. foltz, 2015/01/27 21:56:09]

Should we CHECK that controller_ == nullptr - assuming each time this is called
is a frame attach/detach/re-attach?  Or can controller_ be swapped directly?

[whywhat, 2015/01/28 01:52:37]

You mean that either controller_ or controller is null? We probably should.

+  // event if needed. Ignore a null or the same controller though.
+  if (controller != nullptr && controller_ != controller)
+    updateAvailableChangeWatched(controller->isAvailableChangeWatched());
+  controller_ = controller;
+}
+
+void PresentationDispatcher::updateAvailableChangeWatched(bool watched) {
+  ConnectToPresentationServiceIfNeeded();
+  if (watched) {
+    presentation_service_->GetScreenAvailability(

[mark a. foltz, 2015/01/27 21:56:09]

The lifetime of the PresentationDispatcher is tied to the lifetime of the frame,
right.  What if the frame is destroyed before the callback fires?  Should this
class have a WeakPtrFactory?

[whywhat, 2015/01/28 01:52:38]

I don't know for sure. But my guess is that the callback is stored on the
renderer side of Mojo, so if the frame dies, Mojo part of it knows not to run
the callback. GeolocationDispatcher passes Unretained(this) the same way.

+blundell, what do you think?

[qsr, 2015/01/28 15:41:10]

 The callback is stored on the persentation_service_ proxy, so as it will be
deleted with this class, this is perfectly fine.

+        base::Bind(&PresentationDispatcher::OnScreenAvailabilityChanged,
+                 base::Unretained(this)));
+  }
+}
+
+void PresentationDispatcher::OnScreenAvailabilityChanged(bool available) {
+  if (!controller_)
+    return;
+
+  // Reset the callback to get the next event.
+  updateAvailableChangeWatched(controller_->isAvailableChangeWatched());
+
+  controller_->didChangeAvailability(available);
+}
+
+void PresentationDispatcher::ConnectToPresentationServiceIfNeeded() {
+  if (presentation_service_.get())
+    return;
+
+  render_frame()->GetServiceRegistry()->ConnectToRemoteService(
+      &presentation_service_);

[mark a. foltz, 2015/01/27 21:56:09]

Can this ever fail?  Do we need to CHECK the result or will that happen
upstream?

[whywhat, 2015/01/28 01:52:37]

This either calls the service's CreateService immediately or later as a pending
connection request when the ServiceRegistry is bound in render_host_impl. Is it
possible for the dispatcher to call this before the registry is bound and what
happens in that case (does Mojo suspend all calls until the service is
created?), I don't know.

Colin?

[qsr, 2015/01/28 15:41:10]

It depends a lot what you mean by fail. After this call, you are guaranteed that
presentation_service_ is usable, and you can start calling method immediately.
But if the other side doesn't bind it, your calls will just be lost. The way it
works is that at this point, you create a pair of pipe, you bind one to your
proxy, and you send the other away to be bound to an implementation. You have no
guarantee that this will happen, but you can start writing message to your end
of the pipe immediately.

+}
+
+}  // namespace content