New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 10 users

Issue metadata

Status: Fixed
Closed: Mar 2017
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression

Sign in to add a comment

HTML5 Audio is broken when loaded from cache

Reported by, Dec 30 2016 Back to list

Issue description

Chrome Version       : 55.0.2883.95 (Official Build) (64-bit)
URLs (if applicable) :
Other browsers tested:
     Safari: ok
    Firefox: ok
         IE: -

What steps will reproduce the problem?
(1) Visit
(2) Reload the page
(3) Check the "Last Event" for the 3rd Audio Element - if it's `canplaythrough`, go to step 2. If it's `loadedmetadata` proceed to 4.
(4) Attempt to play the 3rd Audio Element

What is the expected result?
Audio should play. `play`, `timeupdate` and `ended` events should fire.

What happens instead?
Audio does not play. The `waiting` event is fired instead.


Comment 1 by, Jan 4 2017

Labels: Needs-Triage-M55
Components: Blink>Media>Audio
Labels: -Type-Bug -Needs-Triage-M55 M-56 OS-Mac Type-Bug-Regression
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on Mac OS 10.12 using chrome latest stable M55-55.0.2883.95 by following steps mentioned in the original comment. By clicking on the play button of 3rd audio element the 'waiting' even is fired.

Bisect Information:
Good build: 55.0.2871.0
Bad build:    55.0.2873.0

Change Log:

Unable to invoke bad builds during python tool bisect, so providing manual bisect information. As per the above log observing only one change which is related to Html5, Hence assigning to the same.

xing.xu@ Do you have any idea on this bug? Incase of this issue is not related to your change please feel free to reassign to the concerned dev person.


Comment 3 by, Jan 4 2017

Patch is about dialog, nothing to do with audio.  And didn't use dialog. So how about someone audio related check this first?
This bug appears to be fixed on the Canary version (57.0.2977.0), but not the beta version (56.0.2924.51).

Comment 5 by, Jan 13 2017

Labels: Hotlist-Enterprise
Labels: -Pri-3 Pri-1
Hey dgreid@, are you the right person to look into this, or do you know who is?

I'm upgrading this bug to P1 because it's currently impacting standardized testing on CrOS and we're already receiving user reports.

Comment 7 by, Jan 14 2017

Way too far up the stack for me if it is happening on Mac as well.

Comment 8 by, Jan 14 2017

Hey dalecurtis@, would you be the right person to take a look at this, or do you know who is?
Same problem here.. Broken on 55.0.2883.95, works well on Canary 58.0.2990.0.
Labels: Needs-Bisect
This site makes 12 connections for the audio files, this exceeds the max of 6 connections for an HTTP connection. This is probably issue 58467, +hubbe in case there's anything interesting from a network perspective that we could be doing better here.

If you have assets like this you should mark the tags as preload=none, or preload=metadata to cycle down the connections. preload=auto expects that playback will begin shortly.

Seems like another bisect should be done too.
Labels: -Needs-Bisect hasbisect-per-revision
Tested in chrome stable #55.0.2883.95 on Mac 10.12.2 and able to reproduce the issue. Not able to reproduce the issue in beta #56.0.2924.67 dev #57.0.2986.0 and canary #58.0.2991.0. So providing the reverse bisect details.

Bisect Info:
Good Build: 56.0.2910.0 (Revision- 430103)
Bad Build: 56.0.2909.0 (Revision- 429737)

You are probably looking for a change made after 430085 (known good), but no later than 430086 (first known bad).


From the CL above, assigning the issue to the concern owner. Probably this change could have fixed the issue.

@ watk : Kindly take a look and please help us to reassign this issue to a right owner if not with respect to this change.

Looks like this might be fixed by Dan's recent changes. I'd expect latest M57 to work then though.

Comment 14 by, Jan 24 2017

sandersd@ and I took a look at this. This is what appears to be happening:

* We add players in the idle state initially
* RendererWebMediaPlayerDelegate performs an idle player cleanup after 8 players are added
* So sometimes this third player is idle suspended because the cleanup runs almost immediately after it's created before loading has ever progressed (last_time_loading_progressed_.is_null()). The logic it uses to accept the suspend request is:
  if (last_time_loading_progressed_.is_null() ||
        (tick_clock_->NowTicks() - last_time_loading_progressed_) >
* That should be fine, though, because the next time didLoadingProgress is called we'll resume the player.

So our hypothesis is that didLoadingProgress() is not called. This code relies on the invariant: after load() is called, if any reads succeed then didLoadingProgress will be called at least once. Looks like this isn't happening in this case. 

If you open the devtools network tab you can see different network behavior in the cases where it works and doesn't work. When it works as expected you can see network requests for the media files (beep*.ogg) (whether they're satisfied by the disk cache or not doesn't matter). When it doesn't work there are zero requests for the media files (but they're still loading from somewhere). I don't understand the latter mode. hubbe@? 

Comment 15 by, Jan 25 2017

Some observations:
1. the bug cannot be reproduced inside an iframe. The last event will always be `canplaythrough`.
2. also, the bug cannot be reproduced on the `file://` protocol.
2. the devtools network tab not showing the ogg files should be treated as a separate bug. It most certainly **is** a bug, but it's not directly related to the current one.
Status: Fixed (was: Assigned)
Unable to reproduce this on ToT. Seems very likely that Dan's changes fixed it.

Sign in to add a comment