This affects Safari 11+. Reproducible test case: https://gist.github.com/eirslett/9e4da60e418ef490c94f3ba14cc4e7cd Preconditions: 1) Set up a video to be played, add event listeners to the video element 2) Trigger play programmatically, but without a user interaction first 3) Expect video playback to fail/be denied. OK 4) Expect an "error" event to be dispatch from the video element: FAILS The video element triggers a "playing" event, but since playback was denied, one would expect an "error" event to be triggered instead?
> This affects Safari 11+. Just to clarify, are you saying that Safari 10 worked correctly, but Safari 11 does not? Does this affect any live websites?
<rdar://problem/34823898>
This is intentional. Many websites never check the promise returned by ply(), and leave their player UI in a broken state.
(In reply to Alexey Proskuryakov from comment #1) > > This affects Safari 11+. > > Just to clarify, are you saying that Safari 10 worked correctly, but Safari > 11 does not? Does this affect any live websites? To be honest I only tested in Safari 11, it's reproduced by the feature where you disable autoplay of videos for a website, which is enabled by default in Safari 11 - I'm not sure if it's implemented in Safari 10 (but disabled by default?)
(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.
(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.