HTMLME::HasPendingActivity(), when attached to MSE, currently always returns true. Outside of the common cases (seeking, not paused, delaying load event, or having pending events to dispatch), HTMLME+MSE returns true because:

(A) HTMLME's network_state_ == kNetworkLoading (usually, unless error reported).
  WMPI adjusts this between Loading/Idle based on Downloading notifications from its DataSource (not when MSE is attached). The analogue in MSE world might be to have SourceBuffer::HasPendingActivity() return true when either their append or remove async task runner is pending firing. (I'm not fully convinced that ignoring SourceBuffer pending tasks and just canceling them in SourceBuffer::Dispose() is fully safe, though it could be.)

and

(B)
 literally when |media_source_| is set. In long-ago, pre-oilpan, there was concern added that durationchange (percolating through pipeline) might fire. If HasPendingActivity() is false for all of HTMLME+MSE and they're otherwise unreachable, HTMLME::Dispose() will cleanly shutdown WMPI, not passing on such events to HTMLME like durationchange.

This is potentially high-impact.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f8109d5f3e9c233ec035f2baaba61c458a1ba909

commit f8109d5f3e9c233ec035f2baaba61c458a1ba909
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Wed Jan 09 03:18:48 2019

MSE: Allow GC of inactive, unreferenced, HTMLME with MSE still attached

This change is intended to reduce runtime memory usage in cases where
inactive, unreferenced HTMLMediaElement connected to MediaSource API
would never previously have been garbage collected.

To enable their collection, this change allows HTMLME, MediaSource and
SourceBuffer ::HasPendingActivity() methods to return false in cases
where have no pending activity even though they might be
connected/attached.

On the Blink side, this CL includes upgrades from Member<> to
TraceWrapperMember<> to keep wrappers for otherwise
HasPendingActivity()==false objects alive when they are wrapper-traced
from an alive object. Otherwise, event dispatch on them might fail even
though they are still alive according to GC, for example.

Note that an unrevoked MediaSource objectUrl can keep an otherwise
unreferenced HTMLME+MSE collection of objects "alive" still. Comment is
added accordingly for that case.

BUG=881548
TEST=Manual tests confirmed GC of HTMLME+MSE occurs when references are
dropped by JS and no work is pending; major upgrade of
mediasource-htmlmediaelement-lifetime.html web test.


Change-Id: I873d5408daca556fb375624e39347f5fa2fb3d55
Reviewed-on: https://chromium-review.googlesource.com/c/1383434
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#621029}
[modify] https://crrev.com/f8109d5f3e9c233ec035f2baaba61c458a1ba909/media/blink/websourcebuffer_impl.cc
[modify] https://crrev.com/f8109d5f3e9c233ec035f2baaba61c458a1ba909/third_party/blink/renderer/core/html/media/html_media_element.cc
[modify] https://crrev.com/f8109d5f3e9c233ec035f2baaba61c458a1ba909/third_party/blink/renderer/core/html/media/html_media_element.h
[modify] https://crrev.com/f8109d5f3e9c233ec035f2baaba61c458a1ba909/third_party/blink/renderer/modules/mediasource/media_source.cc
[modify] https://crrev.com/f8109d5f3e9c233ec035f2baaba61c458a1ba909/third_party/blink/renderer/modules/mediasource/media_source.h
[modify] https://crrev.com/f8109d5f3e9c233ec035f2baaba61c458a1ba909/third_party/blink/renderer/modules/mediasource/source_buffer.cc
[modify] https://crrev.com/f8109d5f3e9c233ec035f2baaba61c458a1ba909/third_party/blink/renderer/modules/mediasource/source_buffer.h
[modify] https://crrev.com/f8109d5f3e9c233ec035f2baaba61c458a1ba909/third_party/blink/renderer/modules/mediasource/source_buffer_list.h
[modify] https://crrev.com/f8109d5f3e9c233ec035f2baaba61c458a1ba909/third_party/blink/web_tests/http/tests/media/media-source/mediasource-htmlmediaelement-lifetime.html

https://crash.corp.google.com/browse?q=product_name%3D%27Chrome%27+AND+expanded_custom_data.ChromeCrashProto.channel%3D%27canary%27+AND+STRPOS%28expanded_custom_data.ChromeCrashProto.magic_signature_1.name%2C+%27%5BOut+of+Memory%5D%27%29+%3E+0

Shows daily volume of OOM crashes on canary, will be interesting to see if this has an effect.

The NextAction date has arrived: 2019-01-10

@#5, the first Canary containing #4 is 73.0.3667.0, which per omahaproxy has current reldate of today (1/10/2019). No renderer OOM crashes seen there yet.

I'll look again tomorrow morning PST.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/747094d33bece7ac282aca46b7be74c8f0c69325

commit 747094d33bece7ac282aca46b7be74c8f0c69325
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Thu Jan 10 21:53:11 2019

MSE: Refactor htmlmediaelement-lifetime layout test

Recent r621029 upgraded the coverage of this layout test, but tests too
many concerns combined into a small number (3) of sub-tests. This change
refactors the layout test to have sub-tests that incrementally build on
each other to help focus on specific concerns in each sub-test. Further
refactoring work may become necessary in the future.

BUG=881548

Change-Id: I2a60b88e338ff34197820b34860aadcce1023229
Reviewed-on: https://chromium-review.googlesource.com/c/1404491
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#621757}
[modify] https://crrev.com/747094d33bece7ac282aca46b7be74c8f0c69325/third_party/blink/web_tests/http/tests/media/media-source/mediasource-htmlmediaelement-lifetime.html

The NextAction date has arrived: 2019-01-11

@#5, on Canary, overall OOM crash counts, and also on just renderer OOM crash counts, before and after #4 (73.0.3667.0): any variance is within the noise; the crash counts seem roughly the same unfortunately.

Though #10 doesn't show any perceivable difference on Canary, I'll check 73 Beta after it's been out for a bit.