Re: Lifetime of new Audio()

On Jan 31, 2011, at 4:57 PM, Adrian Bateman wrote:

> 
> 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 the example that I gave originally:
> 
> 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.
> I think this goes against what Jonas was saying.
> 
> On Sunday, January 30, 2011 7:44 PM, Jonas Sicking wrote:
>> So in this case I think yes, playing should ensure that the object
>> doesn't get GCed. Or rather, GC should not stop the sound from
>> playing. Technically you could push the sound file to the sound
>> subsystem and then destroy the element as that would be
>> indistinguishable for everyone. At least as long as no event handlers
>> are attached to the element.
> 
> We're considering removing the readyState check from potentially playing
> in our implementation for 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.
> 
> If you agree I will file a bug requesting this change.
> 
  I agree that this would be a good change.

eric

Received on Tuesday, 1 February 2011 01:38:20 UTC