Closed Bug 784932 Opened 9 years ago Closed 9 years ago
<audio>.buffered changes everytime <audio>.current
Time changes (inc . within buffered range)
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120814224555 Steps to reproduce: I was creating a canvas wrapper for an audio element, and I use mouse to rotate a knob. I noticed the buffer indicator was blinking when changing currentTime, even when the audio have been fully buffered. Actual results: The audio.buffered property empties itself then comes back to correct buffering information when audio.currentTime is changed. Expected results: The audio.buffered property should not change when the requested portion of audio have already been buffered.
Did you observe this behavior in Firefox 14?
Confirmed in 15 Beta and Trunk. It' WFM in 14 Release.
Last good nightly: 2012-05-27 First bad nightly: 2012-05-28 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=133aa3a2ef0a&tochange=79262a88881d
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Paul Silaghi [QA] from comment #4) Got the same Range over here, too. Maybe regressed by Bug 755533?
Component: General → Video/Audio
Ah, so in nsHTMLMediaElement::GetBuffered() only returns buffered ranges if we in readyState >= HAVE_CURRENT_DATA, and in bug 755533 we changed nsHTMLMediaElement::SeekStarted() to set the readyState to HAVE_METADATA...
I think we should change the former condition...
Simple fix: allow HTMLMediaElement.buffered to return results when readyState > HAVE_NOTHING.
Assignee: nobody → cpearce
Attachment #655513 - Flags: review?(roc)
Attachment #655513 - Flags: review?(roc) → review+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.