Add srcObject attribute of type MediaStream to HTMLMediaElement.

third_party/WebKit/Source/modules/mediastream/HTMLMediaElementMediaStream.h

+// 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.
+
+#ifndef HTMLMediaElementMediaStream_h
+#define HTMLMediaElementMediaStream_h
+
+#include "core/html/HTMLMediaElement.h"
+#include "modules/ModulesExport.h"
+#include "platform/Supplementable.h"
+#include "platform/heap/Handle.h"
+
+namespace blink {
+
+class MediaStream;
+
+class MODULES_EXPORT HTMLMediaElementMediaStream final : public NoBaseWillBeGarbageCollectedFinalized<HTMLMediaElementMediaStream>, public WillBeHeapSupplement<HTMLMediaElement> {
+    WILL_BE_USING_GARBAGE_COLLECTED_MIXIN(HTMLMediaElementMediaStream);
+    USING_FAST_MALLOC_WILL_BE_REMOVED(HTMLMediaElementMediaStream);
+public:
+    DECLARE_VIRTUAL_TRACE();
+    static MediaStream* srcObject(HTMLMediaElement&);
+    static void setSrcObject(HTMLMediaElement&, MediaStream*);
+
+private:
+    HTMLMediaElementMediaStream();
+    static HTMLMediaElementMediaStream& from(HTMLMediaElement&);
+    static const char* supplementName();
+
+    PersistentWillBeMember<MediaStream> m_srcObject;

[haraken, 2016/03/18 23:37:40]

Are you sure that the Persistent handle doesn't cause a leak?

- HTMLMediaElement and HTMLMediaElementMediaStream have the same lifetime.
- HTMLMediaElementMediaStream has a persistent to MediaStream.
- If the MediaStream has a strong reference to the DOM tree that contains the
HTMLMediaElement, there is a cycle.

(This issue will be gone once we remove the WillBe types, which will happen
soon.)

[Guido Urdaneta, 2016/03/20 12:16:30]

I ran a few experiments and observed that the lifecycles of the HTMLMediaElement
and the MediaStream objects were the same with assigment using the srcObject
attribute as with assigment via the src attribute and URL.createObjectURL. Note
that with the src attribute there is no Persistent reference. Thus, I think the
Persistent reference here changes nothing, given how things work today. This was
true with and without Oilpan.

However, that doesn't mean things are perfect.
For example, once a MediaStream is assigned to an element, it is registered in
MediaStreamRegistry, which has a persistent reference to the MediaStream. The
MediaStreams are GC'ed only when the registry is stopped.

There is also some reference from MediaStream to the DOM tree, although I don't
know exactly where it is. This is a brief summary of my experiments:

Experiment 1:
var v = document.createElement('video')
var ms = null
navigator.getUserMedia({video:true}, stream=>{ms=stream}, _=>{})
v = null;
gc(); // video is released
ms = null;
gc(); // mediastream is released

Experiment 2:
var v = document.createElement('video')
navigator.getUserMedia({video:true}, stream=>{v.srcObject=stream}, _=>{})
v.srcObject = null
gc(); //nothing is released
v = null
gc(); //video is released
// Reload page
gc(); //mediastream is released

Experiment 3:
var v = document.createElement('video')
navigator.getUserMedia({video:true}, stream=>{v.srcObject=stream}, _=>{})
v = null
gc(); //nothing is released
// Reload document
gc(); // video and mediastream are released

Like I said, the experiments above work the same for both srcObject and src
assigment, with and without oilpan.

My conclusion is that we should investigate this further.
I don't think this should block this CL, although it might be possible that
after we improve other things this Persistent reference might make a difference.
WDYT?

+};
+
+} // namespace blink
+
+#endif