Eagerly sweep MediaKeySession objects.

Source/modules/encryptedmedia/MediaKeysController.h

Index: Source/modules/encryptedmedia/MediaKeysController.h
diff --git a/Source/modules/encryptedmedia/MediaKeysController.h b/Source/modules/encryptedmedia/MediaKeysController.h
index e3c7a230525fe8a31341048c8eb9e4f1bfd645eb..450a6d0e8d747ea97b36f206ec13a5e0233bbb00 100644
--- a/Source/modules/encryptedmedia/MediaKeysController.h
+++ b/Source/modules/encryptedmedia/MediaKeysController.h
@@ -7,13 +7,11 @@
 
 #include "core/page/Page.h"
 #include "modules/ModulesExport.h"
-#include "wtf/PassOwnPtr.h"
 
 namespace blink {
 
 class ExecutionContext;
 class MediaKeysClient;
-class WebContentDecryptionModule;
 class WebEncryptedMediaClient;
 
 class MODULES_EXPORT MediaKeysController final : public NoBaseWillBeGarbageCollected<MediaKeysController>, public WillBeHeapSupplement<Page> {
@@ -29,6 +27,10 @@ public:
 private:
     explicit MediaKeysController(MediaKeysClient*);
     static const char* supplementName();
+
+    // Raw reference to the client implementation, which is currently owned
+    // by the WebView. Its lifetime extends past any m_client accesses.
+    // It is not on the Oilpan heap.

[haraken, 2015/05/23 23:58:37]

Just help me understand:

- Is this related to the MediaKeySession issue somehow?

- MediaKeysController and Page die at the same time. Page does not outlive the
WebViewImpl. Thus this the m_client cannot be a stale pointer. Is my
understanding correct?

[sof, 2015/05/24 05:28:16]

That matches mine, essentially. The last part is the key one, the non-heap
WebViewImpl lives longest, hence raw pointers to it from the heap "will work
out". 

     MediaKeysClient* m_client;
 };