Bug 177867 - Unexpected "playing" event triggered when video playback fails
Summary: Unexpected "playing" event triggered when video playback fails
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: Safari 11
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-10-04 05:41 PDT by Eirik Sletteberg
Modified: 2017-10-05 07:22 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eirik Sletteberg 2017-10-04 05:41:37 PDT
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?
Comment 1 Alexey Proskuryakov 2017-10-04 16:35:40 PDT
> 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?
Comment 2 Radar WebKit Bug Importer 2017-10-04 16:36:04 PDT
<rdar://problem/34823898>
Comment 3 Jer Noble 2017-10-04 17:10:38 PDT
This is intentional. Many websites never check the promise returned by ply(), and leave their player UI in a broken state.
Comment 4 Eirik Sletteberg 2017-10-05 05:21:32 PDT
(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?)
Comment 5 Eirik Sletteberg 2017-10-05 05:30:47 PDT
(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.
Comment 6 Jer Noble 2017-10-05 07:22:30 PDT
(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.