- From: Andres Gomez <agomez@igalia.com>
- Date: Fri, 08 Nov 2013 12:57:08 +0200
- To: whatwg@lists.whatwg.org
Hi, because of my recent work related to a bug and test in WebKit, I've gotten to deal with the HTML5 media element's "seeking" algorithm and "seeked" event. During my analysis I was unable, following the specs preview, to determine whether on specific conditions, after a "seek" request a "seeked" event would be received. The cases could be more complicated but, trying to put it simple, in the "seeking" algorithm of the specs: http://dev.w3.org/html5/spec-preview/media-elements.html#seeking We can read on the step 7, that, on certain conditions: "... If there are no ranges given in the seekable attribute then set the seeking IDL attribute to false and abort these steps." Hence, we won't walk the following steps, including the last ones, 13 and 14, which would fire the "timeupdate" and "seeked" events. However, reading the events summary for the "seeked" one: http://dev.w3.org/html5/spec-preview/media-elements.html#event-media-seeked We can read that it is "Fired when...": "The seeking IDL attribute changed to false." ... which is what happens in the mentioned step 7 of the "seeking" algorithm. Because of this, I'm unsure whether a "seeked" (and "timeupdate" ?) event should be fired when the conditions in step 7 happen. I've checked with Chromium on Ubuntu 13.04 and it doesn't fire the event. However, although I don't have enough experience in the matter, it seems to me that the most consistent behavior would be to fire the "seeked" event even when those conditions happen, so the user can have some feedback upon their "seek" request. In any case, even if the expected behavior would be the one implemented in Chromium, not firing the event, it seems to me that it should be stated more explicitly in the specs. Comments are welcome :) -- Br, Andres
Received on Friday, 8 November 2013 10:57:49 UTC