490564 - audio controls are stuck hidden after an error occurs

Status: RESOLVED WORKSFORME

(Toolkit :: Video/Audio Controls, defect)

Description

[Hsiao-Ting Yu (Littlebtc)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090428 Minefield/3.6a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090428 Minefield/3.6a1pre

In a <audio>'s live demo with src changed by DOM in JavaScript, the controls of <audio> will disappear unexpectedly sometimes. 

Reproducible: Sometimes

Steps to Reproduce:
1. Go to the demo page.
2. Refresh the page again and again until the controls of <audio> disappear.
Actual Results:  
The controls of <audio> will disappear sometimes.

Expected Results:  
Controls should be always there every time when the page is loaded.

This happens in both 3.5b5pre and 3.6a1pre. The bug didn't exist on Firefox 3.1 beta 3.

Comment 1

[Ria Klaassen (not reading all bugmail)]

The site times out here.

Comment 2

[Hsiao-Ting Yu (Littlebtc)]

Attachment: The test webpage

Test page attached.  Run index.html to reproduce the problem.

Comment 3

[Hsiao-Ting Yu (Littlebtc)]

Attachment: Screenshot

Comment 4

[Ria Klaassen (not reading all bugmail)]

Thanks! Confirmed on Window XP. Regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d74e551f46a3&tochange=7c6ef292bca3

Comment 5

[Justin Dolske [:Dolske]]

I'm guessing that an error is happening a some point during the load of a media resource, and so bug 481040 is removing the controls when that happens (because the media's in an error state, so you can't do anything with it).

Comment 6

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

Blocking on the assumption that we have a regression in playing this content.

Comment 7

[Justin Dolske [:Dolske]]

There is indeed an error event firing. I see one right as the page is initially loading. Probably because you have:

<audio id="audio" src="#" class="shadow" controls>

So it's trying to load the page URL ("#" == "http://moztw.org/demo/audioplayer/"), so unless you're doing something clever with returning varying content based on the accept header, the <audio> backend isn't going to be happy with trying to play HTML. But it looks like the media source is later changed to a URL like http://moztw.org/demo/audioplayer/audio/01.ogg, so this initial error is a bug in the site.

But there's also a but in the controls, since a successful media source is set after the error, the controls should return when the error condition goes away. We should pop the controls back into existence after a loadstart fires... If this was a <video> we'd fade them back in with the next mouseover, but since it's a <audio> the mouseover actions are disabled (because we were expecting the controls to always stay visible).

The site should still be fixed, to prevent the controls from flashing in and out of existence when this happens. I think removing the src attribute entirely is supposed to do that (from a quick skim of the spec's resource selection algorithm).

Comment 8

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

I don't think we need to block release on this, but it certainly would be nice to fix the controls so they appear after an error has been resolved.

Comment 10

[Justin Dolske [:Dolske]]

Not actively working at this at the moment.

Comment 11

[Liviu Cirdei]

User Agent 	Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID 	20160516030211

Works for me on latest Nightly so I will close the bug. If anyone can still reproduce the issue on a current build, feel free to reopen it.