RESOLVED FIXED 177920
Autoplay muted videos still stop playback of other streaming apps in the background
https://bugs.webkit.org/show_bug.cgi?id=177920
Summary Autoplay muted videos still stop playback of other streaming apps in the back...
Jon Lee
Reported 2017-10-05 00:26:48 PDT
We are still getting reports of b163993 even after r211240. Since that already shipped in iOS 11, tracking further work here.
Attachments
Patch (6.82 KB, patch)
2017-10-24 13:29 PDT, Jer Noble
no flags
Patch for landing (5.39 KB, patch)
2017-10-24 15:13 PDT, Jer Noble
no flags
Patch for landing (5.45 KB, patch)
2017-10-25 08:47 PDT, Jer Noble
no flags
Radar WebKit Bug Importer
Comment 1 2017-10-05 00:27:17 PDT
Ibrahim Ennafaa
Comment 2 2017-10-13 13:19:14 PDT
Hi guys, It looks like there was a regression on this bug. It reappeared with iOS11. Where can I follow its resolution? Is there another ticket to follow? Thanks, Ibrahim
Jer Noble
Comment 3 2017-10-23 16:12:47 PDT
The underlying cause seems to be the order in which HTMLMediaElement ivars are constructed. The MediaElementSession is created before m_isPlayingToWirelessTarget is initialized to false (so therefore, is sometimes true), and when it checks whether the element canProduceAudio(), that check will sometimes return true (because m_isPlayingToWirelessTarget is true). TL,DR: other audio is being interrupted because the PlatformMediaSessionManager thinks the media element is AirPlaying.
Jer Noble
Comment 4 2017-10-24 13:24:59 PDT
*** Bug 178743 has been marked as a duplicate of this bug. ***
Jer Noble
Comment 5 2017-10-24 13:29:24 PDT
Eric Carlson
Comment 6 2017-10-24 13:38:11 PDT
Comment on attachment 324712 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=324712&action=review > Source/WebCore/html/HTMLMediaElement.cpp:489 > +void HTMLMediaElement::setMediaSession(std::unique_ptr<MediaElementSession>&& mediaSession) Why do some of the initialization in the constructor and some here? Why not call this something like "finishSetup" and move everything from the constructor here. Alternatively, instead of requiring the derived classes to create and pass a media session, you can call this "createMediaSession" and allocate the session here.
Jer Noble
Comment 7 2017-10-24 13:48:49 PDT
Comment on attachment 324712 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=324712&action=review >> Source/WebCore/html/HTMLMediaElement.cpp:489 >> +void HTMLMediaElement::setMediaSession(std::unique_ptr<MediaElementSession>&& mediaSession) > > Why do some of the initialization in the constructor and some here? Why not call this something like "finishSetup" and move everything from the constructor here. > > Alternatively, instead of requiring the derived classes to create and pass a media session, you can call this "createMediaSession" and allocate the session here. Yeah, I considered doing the first option; making a virtual "void initialize()" function that did all this. I'll look into this.
Jer Noble
Comment 8 2017-10-24 15:13:48 PDT
Created attachment 324735 [details] Patch for landing
Eric Carlson
Comment 9 2017-10-24 15:36:28 PDT
Comment on attachment 324735 [details] Patch for landing View in context: https://bugs.webkit.org/attachment.cgi?id=324735&action=review > Source/WebCore/ChangeLog:18 > + own ivars (much less their vtables). So instead, we'll create and set the MediaElementSession > + in the HTMLVideoElement and HTMLAudioElement's create() factory methods. Nit: this should be updated.
Jer Noble
Comment 10 2017-10-25 08:47:27 PDT
Created attachment 324827 [details] Patch for landing
WebKit Commit Bot
Comment 11 2017-10-25 10:39:50 PDT
Comment on attachment 324827 [details] Patch for landing Clearing flags on attachment: 324827 Committed r223960: <https://trac.webkit.org/changeset/223960>
WebKit Commit Bot
Comment 12 2017-10-25 10:39:52 PDT
All reviewed patches have been landed. Closing bug.
Ibrahim Ennafaa
Comment 13 2017-10-25 12:57:41 PDT
Hi, Do you have an idea of when the patch will be available to the public and which iOS version will benefit?
Nourdine Dahmani
Comment 14 2017-11-20 07:44:47 PST
Hi, could we please get any information about the delivery of this fix? That could be very helpful. It is something that could be expected in the coming days?
Jer Noble
Comment 15 2017-11-21 09:06:32 PST
If you have an Apple Developer account, you can test out this fix on the latest beta seed of macOS 10.13.2 and iOS 11.2.
Usman
Comment 16 2018-05-08 06:01:54 PDT
I noticed if there are multiple videos on a page and any of the video does not have `muted=true` but have autoplay and playsinline enabled, the background app paused if a video which have muted, playsinline, autoplay attributes starts playing. The sequence of videos does not matters: https://jsfiddle.net/msta5bcr/ it can be reproduce here where first video have muted=true and will autoplay while a video down below the page dont have muted=true, and if Spotify is playing music in background the iPhone will pause it.
Note You need to log in before you can comment on or make changes to this bug.