613312 - Throbber shows until user starts playback on preload=metadata videos

Status: NEW

(Toolkit :: Video/Audio Controls, defect)

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

Sometimes when a preload=metadata video loads, the throbber remains on until you play the video. For example, see URL, you may need to reload the page a few times for it to happen.

I _suspect_ this is because the throbber is showning whenever the video is in readyState==HAVE_CURRENT_DATA, and when we suspends the load due to preload=metadata, we happen to only have only decoded one frame.

We could probably get around this by hiding the throbber when readyState==HAVE_CURRENT_DATA && networkState==NETWORK_IDLE.

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to comment #0)
> I _suspect_ this is because the throbber is showning whenever the video is in
> readyState==HAVE_CURRENT_DATA, and when we suspends the load due to
> preload=metadata, we happen to only have only decoded one frame.

I take it back. It seems the real problem is that we're not getting a transitionEnd event when the CSS transition is fading out the statusOverlay. It looks like the logic to perform the fade out is correct, but sometimes when it tries to initiate the fade out, but the fade out never starts.

Comment 2

[Justin Dolske [:Dolske]]

blocking+ since this would be highly distracting, and makes preload=metadata rather painful.

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

I'm pretty sure this is caused by the same issue as bug 620317; we're not receiving a transitioend event which hides the throbber/statusOverlay because we're cancelling the transition before its delay has expired and thus before the transition has actually started.

I've tested with my patch from bug 620317, and I can't reproduce this bug with that bug's patch applied.

Comment 4

[Frank Yan (:fryn)]

I (In reply to comment #3)
> I've tested with my patch from bug 620317, and I can't reproduce this bug with
> that bug's patch applied.

I can't reproduce this bug with that bug's patch applied either.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage