User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090125 Minefield/3.2a1pre, Ant.com Toolbar 1.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090125 Minefield/3.2a1pre, Ant.com Toolbar 1.2 Dragging the current position marker to yet to be downloaded portions of the video (or randomly clicking on bar) causes video to fail and not be able to be restarted without reloading the page. Reproducible: Always Steps to Reproduce: 1. Visit http://www.double.co.nz/video_test/test5.html (or any video test using native controls) 2. Press play, wait however long you want 3. Drag the current position thing to past the amount downloaded. (I've also found that clicking random parts of the progress bar however many times you want in rapid succession has the same effect) 4. Try to play video Actual Results: The video will no longer play. You will need to reload the page to get the video to play again. Also, the bar representing the amount downloaded will jump around. Expected Results: It should either 1) not let you or 2) let you and play nothing in yet to be downloaded sections BUT allow you to go back to a downloaded section and resume playing without reloading.

Actually, this problem exists but it might be even more broad. I seem to be getting errors no matter where I move drag it and no matter how much is downloaded.

I see slightly different issues, so conforming following. * The video will no longer play. * the bar representing the amount downloaded will jump around. * You need to wait for video to load * some times the current position jump back to old position I think the reason for last one is because the control will be periodically resetting slider/thumb position to "currentTime". But while loading "currentTime" dont give the value last set. you can test this theory by going to attachment 346840 [details] if video controls are visible my "+5 sec" & "-5 sec" wont work correctly if you hide controls my "+5 sec" & "-5 sec" works as expected. so we need another "currentTime" property may be "currentSetTime". CC ing Chris I also see another issue, see bug 475463

Are you sure what you are seeing is not the cause of excessively long seek times. If you request a seek (by dragging the bar) then play, pause, additional seeks, etc will not work until the seek is completed. You can see the 'seeking' attribute on the video is 'true' if it is still seeking. The 'amount download' will jump around as it 'divide and conquers' its way through the video looking for the correct seek point. The fact that it jumps is a bug in the progress events btw, it's supposed to be suppressing progress events during this time.

It might be. Because, I just tried, clicked up farther in the file, waited a minute and then it did begin to play from that place in the file. So, if you wait a long time it does start again and seemingly from the correct point. Is there a bug for this already so this is a dup? And, would this be one bug or a bug for the seeking, a bug for the glitchy download progress meter, etc. Also, will partial file downloads be supported (so if I want to start at 40 seconds in it downloads from there on like YouTube does). Thanks

(In reply to comment #3) > Are you sure what you are seeing is not the cause of excessively long seek > times. I see this if I move thumb to seek about 4 sec in the attachment 346840 [details]

Slow seeking in HTTP is bug 469408. If you want to test the progress bar with fast seeks, try it with a local file. Local seeks are near instantaneous. Glitchy download progress should be a separate bug. It's a bug with the events being raised rather than the meter I think. There used to be an attribute for setting the start of a video but that was removed from the spec a while back. I believe the W3C is working on a way of specifying such things in the URL.