W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2011

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 24 Aug 2011 16:40:19 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QwGV1-000764-C6@jessica.w3.org>

--- 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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:01 UTC