Implement navigator.mediaDevices.getUserMedia()

Source/modules/mediastream/MediaDevices.cpp

Index: Source/modules/mediastream/MediaDevices.cpp
diff --git a/Source/modules/mediastream/MediaDevices.cpp b/Source/modules/mediastream/MediaDevices.cpp
index 24537ad028652b24b8f408fdaa2e7731527d617d..b8a4aa933599cde3f1f27e301ac4d94af0a03e9a 100644
--- a/Source/modules/mediastream/MediaDevices.cpp
+++ b/Source/modules/mediastream/MediaDevices.cpp
@@ -11,6 +11,10 @@
 #include "core/dom/DOMException.h"
 #include "core/dom/Document.h"
 #include "core/dom/ExceptionCode.h"
+#include "modules/mediastream/MediaStream.h"
+#include "modules/mediastream/NavigatorMediaStream.h"
+#include "modules/mediastream/NavigatorUserMediaErrorCallback.h"
+#include "modules/mediastream/NavigatorUserMediaSuccessCallback.h"
 #include "modules/mediastream/UserMediaController.h"
 
 namespace blink {
@@ -26,4 +30,58 @@ ScriptPromise MediaDevices::enumerateDevices(ScriptState* scriptState)
     return request->start();
 }
 
+namespace {
+
+class PromiseSuccessCallback: public NavigatorUserMediaSuccessCallback {

[Peter Beverloo, 2015/06/23 12:44:16]

You should override the destructor here, to make sure m_resolver will be
removed. Dito for PromiseErrorCallback.

[Peter Beverloo, 2015/06/23 12:44:16]

micro nit: empty space before the colon. For PromiseErrorCallback too.

[hta - Chromium, 2015/06/26 09:28:59]

Just an empty destructor?

https://www.chromium.org/blink/blink-gc was a little unclear about which
destructor gets called when you're inheriting from a GarbageCollectedFinalized
class and have an empty destructor.

[Peter Beverloo, 2015/06/26 12:36:55]

Yeah, an empty one would work (the interesting bits will be in
compiler-generated code).

You're right that the "delete" operator will call the wrong destructor (as the
base class' one is not declared virtual), but
GarbageCollectedFinalized::finalizeGarbageCollectedObject() will manually call
the expected one for you.

+public:
+    PromiseSuccessCallback(PassRefPtrWillBeRawPtr<ScriptPromiseResolver> resolver)
+        : m_resolver(resolver)
+    {
+    }
+    void handleEvent(MediaStream* stream)
+    {
+        m_resolver->resolve(stream);
+    }
+private:
+    RefPtrWillBeRawPtr<ScriptPromiseResolver> m_resolver;
+};
+
+class PromiseErrorCallback: public NavigatorUserMediaErrorCallback {
+public:
+    PromiseErrorCallback(PassRefPtrWillBeRawPtr<ScriptPromiseResolver> resolver)
+        : m_resolver(resolver)
+    {
+    }
+    void handleEvent(NavigatorUserMediaError* error)
+    {
+        m_resolver->reject(error);
+    }
+private:
+    RefPtrWillBeRawPtr<ScriptPromiseResolver> m_resolver;
+};
+
+} // namespace
+
+ScriptPromise MediaDevices::getUserMedia(ScriptState* scriptState, const Dictionary& options, ExceptionState& exceptionState)
+{
+    RefPtrWillBeRawPtr<ScriptPromiseResolver> resolver = ScriptPromiseResolver::create(scriptState);
+
+    NavigatorUserMediaSuccessCallback* successCallback = new PromiseSuccessCallback(resolver);
+    NavigatorUserMediaErrorCallback* errorCallback = new PromiseErrorCallback(resolver);

[Guido Urdaneta, 2015/06/23 10:57:02]

Are you deleting these pointers somewhere?

[Peter Beverloo, 2015/06/23 12:44:16]

These will be stored as Member<>s in UserMediaRequest (note that
NavigatorUserMediaErrorCallback is GarbageCollectedFinalized) - they live on the
Oilpan heap.

This effectively means that the lifetime of these objects is being managed by
garbage collection. There's a lot of conditions to this, but the general
overview is documented in Handle.h/Heap.h and on the following page:

https://www.chromium.org/blink/blink-gc

[hta - Chromium, 2015/06/26 09:28:59]

Just checking .. there's no problem with keeping the pointers as just naked
pointers between here and where they're adopted by UserMediaRequest::create()
below, right? I assume Oilpan will see the raw pointers, and reference counting
won't deallocate them until the reference count is incremented in
UserMediaRequest::create()?

[Peter Beverloo, 2015/06/26 12:36:55]

Having the raw pointers here is fine. In the Oilpan world, you'll see a lot more
of those.

When they're created like this (allocated on line 69), Oilpan can see the
object, but would find (during a GC) that they're not referred to from anywhere,
and would thus free them. That's why this is fine for the early-return case on
line 75.

However, when you create the UserMediaRequest object on line 77, the constructor
will store them in the Member<>s, thus referencing them.

The lifetime of UserMediaRequest itself is somewhat more interesting. It lives
on the Oilpan heap, but actually depends on reference counting by the
WebUserMediaRequest objects (that store a WebPrivatePtr<> to it) when padding it
to the embedder - Chromium. I don't think it has to be a
GarbageCollectedFinalized class, and could simply be refcounted.

That said, it's already being used today and changing that is out of scope of
this CL. It works fine, as long as you call UserMediaRequest::start() on it.

+
+    Document* document = toDocument(scriptState->executionContext());
+    UserMediaController* userMedia = UserMediaController::from(document->frame());
+    if (!userMedia)
+        return ScriptPromise::rejectWithDOMException(scriptState, DOMException::create(NotSupportedError, "No media device controller available; is this a detached window?"));
+
+    UserMediaRequest* request = UserMediaRequest::create(document, userMedia, options, successCallback, errorCallback, exceptionState);
+    if (!request) {
+        ASSERT(exceptionState.hadException());
+        return ScriptPromise::rejectWithDOMException(scriptState, DOMException::create(NotSupportedError, "Creating the request failed - internal error?"));

[Peter Beverloo, 2015/06/23 12:44:16]

Why do you create a new exception here, rather than forwarding the one held in
|exceptionState| (which you ASSERT for)?

[hta - Chromium, 2015/06/26 09:28:59]

Returning the passed-up exception works better, thanks!

+    }
+
+    request->start();
+    return resolver->promise();
+}
+
 } // namespace blink