When you click on the video scrubber progress line it causes a seek operation to be performed by the video element. The seek doesn't actually result in a change in playback position so I'm not sure where it is trying to seek too - perhaps the current position. You also notice this if you click the thumb to drag the scrubber position to a new place. A seek is performed for the time where you clicked on the thumb (which is close to the current position) and another seek is performed for the point where the scrubber thumb ends up. This helps contribute to very slow seek operations due to the extra seek. Steps to reproduce: 1) Load video in URL 2) Click anywhere on the progress line 3) Evaluate in the URL bar: javascript:alert(v1.seeking) 4) It replies 'true' indicating a seek is in progress

Waited for the video to load (w/o clicking play), and clicked the bar: ... videoctl: Got progress media event videoctl: +++ load, 28448856 of 28826786 videoctl: Got progress media event videoctl: +++ load, 28826786 of 28826786 ...clicked here... videoctl: +++ seeking to 0.01 JavaScript error: , line 0: Permission denied for <http://tinyvid.tv> to call method XULElement.QueryInterface on <http://tinyvid.tv>. videoctl: Got progress media event Clicking and holding gives similar results... ... videoctl: +++ seeking to 0.23 videoctl: +++ seeking to 0.24 videoctl: +++ seeking to 0.25 videoctl: +++ seeking to 0.26 ... This was working at one point, I bet it's because I'm not setting .increment on the <scale>, as a result of bug 473103.

Bah. I broke then in the last patch revision in bug 462113. Clicking the bar increments it by the page increment value... Which is set with the |pageincrement| attribute or |pageIncrement| property. Note the difference in case. The switch from setAttribute() to using .property broke as a result. :-( The control fell back to using the default value, which is 10. Since the <scale>'s, err, scale, is in milliseconds, this resulted in tiny seeks. [I'll note that tests probably would have caught this, which are still on my to-do list.]

Will this also resolve the issue of a seek being performed when you click the thumb?

No, but I'm not actually seeing that (at least on my OS X trunk build). Are you sure you're not accidentally moving the mouse a bit after you click, triggering a drag? If you can, new bug please. :)

Pushed http://hg.mozilla.org/mozilla-central/rev/97b4f35003b7

Comment on attachment 359614 [details] [diff] [review] Patch v.1 a+ or blocking+, who will be first? :)

Pushed to 191: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9f4abb4635a1

Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090507 Shiretoko/3.5b5pre and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090507 Minefield/3.6a1pre