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
Last visit > 30 days ago
Closed: Apr 2010
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Issue 25185: timeupdate stops firing when networkState returns to NETWORK_IDLE

Reported by, Oct 19 2009

Issue description

Chrome Version       : (Developer Build Ubuntu build 29381)
OS + version : Ubuntu Jaunty 9.04 and Karmic 9.10
CPU architecture (32-bit / 64-bit): both
window manager : Compiz
URLs (if applicable) :
Behavior in Firefox 3.x (if applicable): Pass
Behavior in Chrome for Windows (optional): Not tested

What steps will reproduce the problem?
1. Go to
2. Press "To end" to skip the first song.

What is the expected result?
The text after played should be updated throughout the song.

What happens instead?
The first time the page is loaded, the text stops after some seconds. The 
second time, it isn't updated at all.

Comment 1 by, Oct 20 2009

Labels: -Area-Misc Area-WebKit Video HTML5

Comment 2 by, Oct 21 2009

Labels: Mstone-X

Comment 3 by, Oct 28 2009

Labels: -OS-Linux OS-All
Probably not Linux-specific.

Comment 4 by, Dec 22 2009

Labels: Internals-Video

Comment 5 by, Dec 22 2009

Labels: -Video

Comment 6 by, Jan 11 2010

Labels: -HTML5

Comment 7 by, Feb 12 2010

Labels: -Mstone-X Mstone-5 Pri-2
Status: Assigned

Comment 8 by, Mar 17 2010

I'm seeing this bug too, using Chrome 5.0.307.11 beta on Mac OS X 10.6.

First playback of a file using an audio element will result in the timeupdate event 
firing off for an indeterminate period, but usually no longer than about 40s 
(sometimes as short as 2s), after which point the timeupdate events stop firing.

At this point calling pause() followed by play() on the element (or clicking twice on the 
pause/play button) will cause timeupdate events to start firing again.  They will then 
continue firing until the track finishes playing.

Comment 9 by, Mar 30 2010

Labels: -Pri-2 Pri-1

Comment 10 by, Mar 31 2010

Status: Started
Have this reproducing and tracked down:

void WebMediaPlayerImpl::OnNetworkEvent() {
  DCHECK(MessageLoop::current() == main_loop_);
  if (pipeline_->GetError() == media::PIPELINE_OK) {
    if (pipeline_->IsNetworkActive())

What happens is the pipeline is triggering OnNetworkEvent() but IsNetworkActive() 
returns false, which makes HTMLMediaElement stop the timeupdate timer:

if (state == MediaPlayer::Idle) {
    if (m_networkState > NETWORK_IDLE) {
    m_networkState = NETWORK_IDLE;

Going to see if this is a bug in our code or a WebKit spec implementation bug (i.e., 
perhaps we're still supposed to fire timeupdate when idle)

Comment 11 by, Mar 31 2010

Hmm.. not seeing anything in the spec that would cause timeupdate to stop firing while 
in NETWORK_IDLE.  Then again.. need to dig around to see if we should even both setting 
our state NETWORK_IDLE :)

Comment 12 by, Mar 31 2010

Another issue is that we seem to be good at deferring ourselves 
(BufferedResourceLoader::EnableDeferIfNeeded) but not good at un-deferring ourselves

Comment 13 by, Mar 31 2010

Alright there's two scenarios that cause the suspend event (i.e. going to NETWORK_IDLE) 
to get fired, which stop our timeupdate events:
  1) We read the whole file (BufferedResourceLoader::OnCompletedRequest)
  2) We defer loading the request (BufferedResourceLoader::EnableDeferIfNeeded)

I've seen #1 happen on small files like the MP3s linked in this report.  I've seen #2 
happen on large files like big movies, but it takes a while to trigger.

Comment 14 by, Mar 31 2010

 Issue 34390  has been merged into this issue.

Comment 15 by, Mar 31 2010

Summary: timeupdate stops firing when networkState returns to NETWORK_IDLE
Updating summary based on latest findings.

No known workaround at the moment.  We've got three options for fixing this:
  1) Patch WebKit to not stop timeupdate events when entering NETWORK_IDLE
  2) Disable our code that sets us back to NETWORK_IDLE and always remain in NETWORK_LOADING
  3) Fix our resource loading bugs

We should do option 1 regardless.  However that alone won't fix scenario 2 as described in comment #13 since we 
never un-defer our request, meaning we still have a timeupdate bug.  Option 3 isn't going to make it in time and 
needs a lot of work.

In my opinion if we can't accurately determine when we should be NETWORK_IDLE versus NETWORK_LOADING (i.e., defer 
and undefer our resource loading), then we're not providing much use to begin with.

Comment 16 by, Apr 2 2010

It's a two-patcher!!

WebKit patch out for review:
Chrome patch out for review:

Comment 17 by, Apr 2 2010

The following revision refers to this bug: 

r43441 | | 2010-04-01 20:03:07 -0700 (Thu, 01 Apr 2010) | 8 lines
Changed paths:

Don't forcibly set our network state to NETWORK_LOADING after media initializes.

We already set the network state to NETWORK_LOADING before we kick off initialization.  Furthermore, we may end up caching the entire media resource and set our network state to NETWORK_IDLE in which case we really don't want to switch back to NETWORK_LOADING.

BUG= 25185 
TEST=covered by layout tests

Review URL:

Comment 18 by, Apr 2 2010

Landed upstream:

Will mark as fixed as soon as patch lands in Chromium.

Comment 19 by, Apr 7 2010

Status: Fixed
Landed in Chromium.

Comment 20 by, Apr 23 2010

 Issue 42367  has been merged into this issue.

Comment 21 by, Jul 19 2010

Labels: -Internals-Video Feature-Media

Comment 22 by, Oct 12 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 23 by, Mar 10 2013

Project Member
Labels: -Area-WebKit -Mstone-5 -Feature-Media Cr-Content Cr-Internals-Media M-5

Comment 24 by, Mar 13 2013

Project Member
Project: playground/bar
Branch : master
Author : Brian Harring <>
Commit : 46a134099fcc6e74883155d6b7e47f5af3d19392

Code Review  +2: Brian Harring
Verified     +1: Brian Harring
Commit Queue   : Chumped
Change-Id      : Iaf08ce3889b276bdf466a3a4cd91eb62196180bd
Reviewed-at    :

Testing bugdroid resolution behaviour

BUG=chromium-os:35805  chromium:158455  chromium-os:34373  chromium:34390 

Comment 25 by, Mar 13 2013

Project Member
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Comment 26 by, Apr 6 2013

Project Member
Labels: -Cr-Content Cr-Blink

Sign in to add a comment