The defaultEventHandler of the class does not distinguish between mouseup/down/click, thus setting currentTime thrice on each click. This seems suboptimal.
(In reply to comment #0) > The defaultEventHandler of the class does not distinguish between mouseup/down/click, thus setting currentTime thrice on each click. This seems suboptimal. just had a look at the code, looks like once currentime is set first time, condition "if (time != mediaElement()->currentTime())" will fail next time as time is already adjusted so won't adjust the time again??
(In reply to comment #1) > just had a look at the code, looks like once currentime is set first time, condition "if (time != mediaElement()->currentTime())" will fail next time as time is already adjusted so won't adjust the time again?? Not necessarily. For some media engines, a seek is asynchronous, and the end result of a seek may not be exactly the time requested. Three calls in a row to seek() could definitely occur. Sounds like setCurrentTime() should only occur for mousedown and mousemove events.
Dimitri, I'll take this one.
Created attachment 143874 [details] Patch
Comment on attachment 143874 [details] Patch Nope, this patch breaks dragging the timeline slider.
Hey, whaddaya know. There's already an "input" message which is fired on input elements during mousedown and mousemove events.
<rdar://problem/11350416>
Created attachment 143879 [details] Patch
Committed r118411: <http://trac.webkit.org/changeset/118411>