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.
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.
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.
The last progress event should occur after the buffered TimeRange object equals the duration.
*** Bug 599205 has been marked as a duplicate of this bug. ***
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.
This seems reasonable, but you need to fire progress before suspend, otherwise it looks as if the download suspended and immediately resumed.
Created attachment 547382 [details] [diff] [review]
Patch v1 - adressed Kinetik remarks.
Is there a minimized test case which I can use to verify this fix?
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.