[Bug 13871] <video> behavior when setting currentTime to current playback position

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13871

--- Comment #6 from Glenn Adams <glenn@skynav.com> 2011-08-24 16:40:17 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > The problem is that the current behavior is not what one would expect. I do not
> > expect a state exception when there is no difference in new and current
> > playback position.
> > 
> > By my interpretation a playback position is not a *new* position unless it is
> > different than the current position. As a consequence, no seek is being
> > requested. So why incur an exception resulting from an erroneous attempt to
> > seek to the current position?
> 
> A few reasons come to mind:
> 
> 1. It's simpler to implement, as you don't have to worry about comparing a
> fixed value with an ever-changing value.
> 
> 2. It's more reliable for page authors, as UI won't break when one happens to
> click the seek bar exactly at currentTime.

Could you describe how an early exit from the seeking algorithm, i.e., without
generating a seeking event, will "break" the page's UI?

I would expect it to act as a NO-OP, simply resulting in no update/change to a
seek bar.

Since various other states on the resource may result in a seek exception, a
realistic UI would not depend on every setting of currentTime to produce a
seeking event in the first place.

> 3. It's impossible to seek in any meaningful way while readyState is
> HAVE_NOTHING.

I agree with this, however, I would assign higher priority to NO-OP semantics
than to raising throwing an exception due to an attempt to seek to the current
position, even when HAVE_NOTHING applies.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 24 August 2011 16:40:21 UTC