Closed Bug 475861 Opened 13 years ago Closed 13 years ago

Clicking video control's scrubber line causes only tiny position change


(Toolkit :: Video/Audio Controls, defect)

Not set





(Reporter: cajbir, Assigned: Dolske)




(Keywords: verified1.9.1)


(1 file)

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
Flags: blocking1.9.1?
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 <> to call method XULElement.QueryInterface on <>.
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.
Assignee: nobody → dolske
Attached patch Patch v.1Splinter Review
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.]
Attachment #359614 - Flags: review?(enndeakin)
Summary: Video scrubber causes a seek when you click anywhere on the scrubber line → Clicking video control's scrubber line causes only tiny position change
Target Milestone: --- → mozilla1.9.2a1
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. :)
Attachment #359614 - Flags: review?(enndeakin) → review+
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [needs 1.9.1 landing]
Comment on attachment 359614 [details] [diff] [review]
Patch v.1

a+ or blocking+, who will be first? :)
Attachment #359614 - Flags: approval1.9.1?
Flags: blocking1.9.1? → blocking1.9.1+
Attachment #359614 - Flags: approval1.9.1?
Pushed to 191:
Keywords: fixed1.9.1
Whiteboard: [needs 1.9.1 landing]
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
Component: Video/Audio → Video/Audio Controls
Product: Core → Toolkit
QA Contact: →
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.