Final media progress event fires before media.buffered TimeRanges are full to 100%

RESOLVED FIXED in mozilla8



6 years ago
6 years ago


(Reporter: Mark Panaghiston, Assigned: padenot)


Windows 7

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [inbound], URL)


(1 attachment, 1 obsolete attachment)



6 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

When attaching a progress event handler that sums the media.buffered TimeRange information, the final progress event occurs before the TimeRange raches the final state of being length 1 with the media.buffered.start(0) = 0 and media.buffered.end(0) = media.duration.

The behaviour varies and appears to depend on how lucky you are as to whether it reaches 100% or not.

The URL that demonstrates the problem, contains a circle player with buffered and currentTime feedback in a ring. It works. The final progress event does not, which is why the white ring does not always fill completely.

Chrome, Safari, iOS Mobile Safari work fine. Opera does not give buffered info.

Reproducible: Always

Steps to Reproduce:
1. Add a media element to a page
2. Attach a progress event handler to the media element that logs the TimeRanges information and the duration.
3. Notice that the final progress event logs does not have the buffered TimeRanges object equal to the duration.

Actual Results:  
Varies but, appears that the last 20% of the file I test with sometimes does not register in the final progress even. Depends on bandwidth and size of the file.

Expected Results:  
The last progress event should occur after the buffered TimeRange object equals the duration.
Ever confirmed: true
Duplicate of this bug: 599205


6 years ago
Assignee: nobody → paul

Comment 2

6 years ago
Created attachment 547129 [details] [diff] [review]
Patch v0 - Send progress when the download is supended.

After a quick gdb session, it appeared that |nsHTMLMediaElement::ResourceLoaded| which sends the "progress" event, is called only when the end of the media is buffered, thus, is the media stops downloading from natural causes (i.e. we reached a range that is already available), "progress" was not fired.

This patch fixes this behavior by sending a "progress" event whenever the download stops, ensuring a correct refresh of the controls, which are relying on this event.

Consequently, this patch fixes bug 599205 too.
Attachment #547129 - Flags: review?(kinetik)
This seems reasonable, but you need to fire progress before suspend, otherwise it looks as if the download suspended and immediately resumed.

Comment 4

6 years ago
Created attachment 547382 [details] [diff] [review]
Patch v1 - adressed Kinetik remarks.
Attachment #547129 - Attachment is obsolete: true
Attachment #547129 - Flags: review?(kinetik)
Attachment #547382 - Flags: review?(kinetik)
Attachment #547382 - Flags: review?(kinetik) → review+


6 years ago
Keywords: checkin-needed


6 years ago
Keywords: checkin-needed
Whiteboard: [inbound]
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
Is there a minimized test case which I can use to verify this fix?

Comment 7

6 years ago

Seek almost at the end of the audio (like 9/10), and then seek at the beginning (like 2/10).

The buffering bar should fill completely, and the progress member (showed in the page for convenience) should consist in only one range.

Without this patch, the buffered range consists in only one range, and the buffered zone doesn't fill the seek bar completely, by an amount which depends on the media downloaded and the bandwidth.
You need to log in before you can comment on or make changes to this bug.