Prevent GC of media elements that are delaying the load event

Prevent GC of media elements that are delaying the load event

The spec requires that "only once a media element is in a state where no
further audio could ever be played by that element may the element be
garbage collected."

The delaying-the-load-event flag is true early during resource
selection, typically until after the loadeddata event is fired.
Preventing GC in this time frame means that the loadedmetadata and
loadeddata events will be fired reliably.

Note that it's still possible to write unreliable code e.g. by using
preload=auto and calling play() in a canplaythrough event handler, but
making that reliable requires loading potentially large amounts of data
that may not ever be used. A spec bug for clarification was filed:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26515

TEST=LayoutTests/media/gc-during-load.html
TEST=LayoutTests/media/avtrack/addtrack.html (no longer flaky)

BUG=397324

[philipj_slow, 2014-08-04 12:07:27]

PTAL

[philipj_slow, 2014-08-04 13:11:00]

Hmm, apparently
http/tests/media/media-source/mediasource-closed-on-htmlmediaelement-destruction.html
assumes that GC will happen while the delaying-the-load-event flag is true. Is
this deliberate? Should it not be possible to create a video element with a
MediaSource and feed it data as it arrives over XHR and insert the video element
into the document only when metadata is known?

[acolwell GONE FROM CHROMIUM, 2014-08-04 15:41:16]

Wouldn't this prevent HTMLMediaElements from ever getting GCed in the
preload=metadata case? I don't believe the HTMLMediaElement is required to
transition to HAVE_CURRENT_DATA in that situation. That particular situation is
really easy to get into with MSE if you only end up appending the init segment
and never append any media segments. Also if a MediaSource is attached and no
bytes are appended, I believe this change would prevent GC as well even if
nothing holds a reference to either. That seems dangerous to me. 

I don't have an alternate proposal yet, but I think the assumption that you will
always get to HAVE_CURRENT_DATA is not quite sound. In the non-MSE case you'll
always have the resource loader to get you out of trouble by signalling some
sort of error or eventually timing out. In the MSE case you don't have such an
automatic signal since the element is always waiting for data from the MSE
object.

[philipj_slow, 2014-08-05 05:23:09]

I tied this into the delaying-the-load-event flag on the assumption that it's
already robust against these kinds of issues. Per spec the flag is set to false
in the preload=none case. However... I can't find that in our implementation.
Maybe it happens deep in some call, but if it doesn't it could explain
https://code.google.com/p/chromium/issues/detail?id=399298

It seems that right now using MSE would easily delay the load event, maybe MSE
should simply never delay it?

If these and any other cases where the delaying-the-load-event flag is currently
not robust is fixed, it seems like a good fit for blocking GC as well.

[philipj_slow, 2014-08-05 18:18:44]

I'm going with a workaround for now: https://codereview.chromium.org/440033003/

Proper fix tracked by https://code.google.com/p/chromium/issues/detail?id=400659