Open Bug 613312 Opened 11 years ago Updated 6 years ago

Throbber shows until user starts playback on preload=metadata videos

Categories

(Toolkit :: Video/Audio Controls, defect)

x86
All
defect
Not set
normal

Tracking

()

Tracking Status
blocking2.0 --- .x+

People

(Reporter: cpearce, Unassigned)

References

()

Details

(Whiteboard: [softblocker])

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.
(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.
Depends on: 613888
blocking+ since this would be highly distracting, and makes preload=metadata rather painful.
blocking2.0: --- → final+
Assignee: nobody → fryn
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.
Blocks: 620317
No longer depends on: 613888
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.
Assignee: fryn → chris
No longer blocks: 620317
Depends on: 620317
Whiteboard: [soft blocker]
Whiteboard: [soft blocker] → [softblocker]
** 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
blocking2.0: final+ → .x+
Assignee: cpearce → nobody
You need to log in before you can comment on or make changes to this bug.