802310 - Adding, removing audio element, then adding another audio element causes strange behaviour

Status: RESOLVED INACTIVE

(Core :: Audio/Video: Playback, defect)

Description

[yo]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120907231657

Steps to reproduce:

The main problem is with the website http://www.radiobattletoads.com/. I've set up a more simple environment for this bug report, here: http://www.radiobattletoads.com/prueba.html

Just follow the steps described in the website: add dinamically an audio element pointing to a stream, remove it, and then add another audio element pointing to the same stream.


Actual results:

The second time you add an audio element, the first seconds from the first one you've added are played, then silence happens until the player reaches the proper starting time, and the player starts playing from where it should be.


Expected results:

The second audio element should have nothing to do with the first one. When the second audio element is added, the stream should start from where it should.

Comment 1

[yo]

I've made a simple regression test. I've tested the site on Firefox 4, 8, 9, 10, 11, 12, 15 and 16.

It seems Firefox 4-10 are unaffected. Firefox 11 onwards are affected.

Comment 2

[Alice0775 White]

Regression window(cached m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/84117219ded0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111125 Firefox/11.0a1 ID:20111125031016
Bad:
http://hg.mozilla.org/mozilla-central/rev/655742c3b022
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111125 Firefox/11.0a1 ID:20111125015409
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=84117219ded0&tochange=655742c3b022


Regression window(cached m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/a4492c6d02b0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111124 Firefox/11.0a1 ID:20111124173310
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/37f51b143fad
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111124 Firefox/11.0a1 ID:20111124181610
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a4492c6d02b0&tochange=37f51b143fad


Suspected : Bug 703379

Comment 3

[Alice0775 White]

Attachment: test2 html

When I open audio(same src) in the other tab again, this problem also happens.

Steps to reproduce:
 1. Open test2 html in New Tab
 2. After audio started, Close the tab several seconds later.
 3. Open test2 html in New Tab again

Actual results:
 Same problem of comment#0 happens

And regression range is same as comment #2

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is a live stream, right?

For better or worse, our behavior is actually allowed by the HTML5 spec. We are allowed to assume that two loads with the same URL represent the same resource.

You could work around this by adding query parameters to make the URLs different.

Comment 5

[yo]

Thanks for the workaround. I'm now applying it to my website, and I'm happy. 

BUT, even when that's allowed by the HTML5 spec, I don't think that this is a good idea for live streams. Spec says nothing about that?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It is a very good idea for non-live streams, and unfortunately we don't have a reliable way to tell whether a resource is a live stream or not.

Comment 7

[yo]

So, do you think the good way to go is discussing this on the html 5 spec?

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes.

Comment 9

[Alice0775 White]

Setting media.cache_size = 0 (restart browser necessary) may help

Comment 10

[Nils Ohlmeier [:drno]]

Mass closing do to inactivity.
Feel free to re-open if still needed.