[Webkit-unassigned] [Bug 177867] Unexpected "playing" event triggered when video playback fails

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=177867

--- Comment #6 from Jer Noble <jer.noble at apple.com> ---
(In reply to Eirik Sletteberg from comment #5)
> (In reply to Jer Noble from comment #3)
> > This is intentional. Many websites never check the promise returned by
> > ply(), and leave their player UI in a broken state.
> 
> I'm not sure I understand, could you please elaborate a bit on that? I argue
> the opposite.
> 
> The bug I reported (or "feature", if it's intentional) will leave player UIs
> in a broken state. If a developer gets a "playing" event from the video
> element, they will (supposedly) change the "play" button in the UI to be a
> "pause" button. If they receive an "error" event, they will change the
> button to a "play button" and show an error message, or something.
> 
> Assume somebody triggers play() on the video element, but the playback
> action is denied, because of the autoplay restriction. The "playing" event
> will still be dispatched (which is what the bug is about). This will lead to
> a broken UI state, because the "play" button will have been made into a
> "pause" button (assuming that's how the developer implemented the UI) - even
> if the video isn't playing.

It’s empirically the case that many existing websites do not check the play() promise, assume that play() will succeed, and do not provide any UI at all until they receive a “playing” event. It is for this reason that we fire “playing” then “paused”; it triggers such sites to show their paused UI. 

If websites all did what you suggested, it wouldn’t be necessary. But here we are.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171005/97da44f4/attachment.html>