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

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Mark Panaghiston]

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.

Comment 2

[Paul Adenot (:padenot)]

Attachment: 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.

Comment 3

[Matthew Gregan [: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

[Paul Adenot (:padenot)]

Attachment: Patch v1 - adressed Kinetik remarks.

Comment 5

[Marco Bonardo [:mak]]

http://hg.mozilla.org/mozilla-central/rev/3252ee5456ff

Comment 6

[u279076]

Is there a minimized test case which I can use to verify this fix?

Comment 7

[Paul Adenot (:padenot)]

http://paul.cx/test/progress.html

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.