- From: <bugzilla@jessica.w3.org>
- Date: Fri, 11 Jul 2014 21:13:55 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515 --- Comment #37 from Jerry Smith <jdsmith@microsoft.com> --- I carried over timeupdate to be consistent with the readyState steps you pointed out. The timeupdate event is supposed to fire when “The current playback position changed as part of normal playback or in an especially interesting way, for example discontinuously.” Based on that, I believe it should be removed from the waiting steps in EME. I also agree with updating the resume steps to handle the playing case. I believe the model is to provide both the canplay and playing events. I propose inserting the playing event as a new step 5: "5. If the element's paused attribute is false, the user agent must queue a task to fire a simple event named playing at the element." Do you have specific race conditions you think we need to manage? Comment 31 specifically mentions two update() calls close together while resume is still in progress. This might result in out of order resume/wait outcomes. Is that your area of concern? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 11 July 2014 21:13:57 UTC