This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12227 - <video> The readyState check in the "potentially playing" definition should not be used to influence GC of media elements
Summary: <video> The readyState check in the "potentially playing" definition should n...
Status: RESOLVED WORKSFORME
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-02 23:49 UTC by Adrian Bateman [MSFT]
Modified: 2011-08-04 05:02 UTC (History)
6 users (show)

See Also:

Attachments

Description Adrian Bateman [MSFT] 2011-03-02 23:49:48 UTC 
See the thread starting at [1] including [2] and [3].

We've analysed this section of the spec.
http://dev.w3.org/html5/spec/video.html#media-playback

This uses the phrase "potentially playing", which is defined as:

"A media element is said to be potentially playing when its paused
 attribute is false, the readyState attribute is either HAVE_FUTURE_DATA
 or HAVE_ENOUGH_DATA, the element has not ended playback, playback has
 not stopped due to errors, and the element has not paused for user
 interaction."
http://dev.w3.org/html5/spec/video.html#potentially-playing

The problem with this is that there is still a race between the GC and the
network in this example:

function playAudio() {
  var a = new Audio("http://www.example.com/music");
  a.play();
}

This means that after the function exits, the behaviour will vary depending
upon whether the GC fires before or after readyState gets to HAVE_FUTURE_DATA.

We propose removing the readyState check from potentially playing this specific scenario so that the element will only be available to be collected on error, when paused, at the end of the media, or if somehow stopped by user interaction.


[1] http://lists.w3.org/Archives/Public/public-html/2011Jan/0438.html
[2] http://lists.w3.org/Archives/Public/public-html/2011Feb/0006.html
[3] http://lists.w3.org/Archives/Public/public-html/2011Feb/0007.html
Comment 1 Philip Jägenstedt 2011-03-03 06:34:35 UTC 
(In reply to comment #0)
> The problem with this is that there is still a race between the GC and the
> network in this example:
> 
> function playAudio() {
>   var a = new Audio("http://www.example.com/music");
>   a.play();
> }
> 
> This means that after the function exits, the behaviour will vary depending
> upon whether the GC fires before or after readyState gets to HAVE_FUTURE_DATA.

After the function exists, paused will be false, so it will be "potentially playing". I think what you mean is that it could be GC'd just before a.play().

Another example where I'm unsure of the behavior is:

var a = new Audio("http://www.example.com/music");
a.canplaythrough = function() { a.play(); };
Comment 2 Adrian Bateman [MSFT] 2011-03-03 18:35:45 UTC 
"Paused is false" is only one part of an AND clause. Before you get to HAVE_CURRENT_DATA then potentially playing is false with the current definition so the element could be collected before the play begins but after calling play().
Comment 3 Philip Jägenstedt 2011-03-03 20:34:06 UTC 
Oops, my bad. The example with the canplaythrough event listener is still racy though, and just removing the readyState check from potentially playing wouldn't fix it.
Comment 4 Ian 'Hixie' Hickson 2011-06-10 19:33:10 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: no spec change
Rationale: I changed the wording a few weeks ago in a way that I believe makes this a non-issue. It now says:

"Media elements must not stop playing just because all references to them have been removed; 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."
Comment 5 Michael[tm] Smith 2011-08-04 05:02:29 UTC 
mass-moved component to LC1