Bug 197688 – Safari resumes autoplay audio elements after getUserMedia

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Szymon Witamborski]

Audio elements that have autoplay attribute start playing after getUserMedia resolves.

Steps to reproduce:

1. have an <audio src="..." loop autoplay> element in the document
   - loop is optional but helps to demonstrate the issue, it could be just a long audio file instead
2. start playback by either:
   - setting "Allow All Auto-Play" for the site
   - starting playback manually
3. stop playback by either:
   - calling pause() method on the play element
   - removing the audio element from DOM
4. request access to the microphone via getUserMedia({ audio: true })

After getUserMedia resolves successfully, the audio element starts playing again, even emits "play" event, even if the element is not in the DOM any more.

I found out that removing the autoplay attribute from the element before calling getUserMedia works around it.

Here's a codepen that demonstrates the issue with the "remove from DOM" approach but it's the same when calling pause() method instead:

https://codepen.io/brainshave/pen/LoVaRj

I'm guessing this is related to Safari lifting up constraints on autoplay after successful getUserMedia request. Resuming explicitly paused elements seems like an undesired side-effect though.

Tested on Safari 12.1 and TP 81. Tried to run Nightly but I seem to be getting a case of https://bugs.webkit.org/show_bug.cgi?id=194808

[Radar WebKit Bug Importer]

<rdar://problem/57674395>

[Jer Noble]

Here's the stack trace of the play() called after getUserMedia() promise returns:

  4 468288 WebCore::HTMLMediaElement::play():entry 
              WebCore`WebCore::HTMLMediaElement::play()
              WebCore`WebCore::HTMLMediaElement::resumeAutoplaying()+0xac
              WebCore`WebCore::Document::updateIsPlayingMedia(unsigned long long)+0x29d
              WebCore`WebCore::MediaStreamTrackPrivate::forEachObserver(WTF::Function<void (WebCore::MediaStreamTrackPrivate::Observer&)> const&) const+0x2bc
              WebCore`WebCore::MediaStreamTrackPrivate::sourceStarted()+0x39
              WebCore`WebCore::RealtimeMediaSource::forEachObserver(WTF::Function<void (WebCore::RealtimeMediaSource::Observer&)> const&) const+0x2bc
              WebCore`WebCore::RealtimeMediaSource::start()+0xad
              WebCore`WebCore::MediaStreamPrivate::startProducingData()+0xad
              WebCore`WebCore::MediaStream::startProducingData()+0xc7

We're also experiencing this same bug with Flipgrid. Our case involves a video tag instead of audio tag, but the result is the same. We also have a codepen here to reproduce - https://codepen.io/mg0stisha/pen/OJPVEzm

Steps to reproduce:
- Play the video
- Pause the video
- Click the 'click me' button (this will remove the video from the DOM)
- Accept the camera permissions
    
Expected: Camera and audio are now in place of the previous video
    
Actual: Camera is shown but audio from previous video is playing

Firefox: no repro
Chrome: no repro
Edge: no repro

This is currently a production issue for us. The user impact is they are watching other students videos, and then they go to record their own video. Upon accepting camera permissions, the audio of the previous videos they watched then plays in the background causing a jarring experience. 

We really want to create a great experience for Safari users, and currently we are recommending users to download Chrome/New Edge. We're also in the process of developing a workaround for this issue, but would love to help get it resolved if possible instead.

Thank you in advance for your help!

[Jer Noble]

This is in HTMLMediaElement.h:

```
    void mediaStreamCaptureStarted() { resumeAutoplaying(); }
```

This doesn't seem right; as it's broadcast to every element in the page when capture is started.

[youenn fablet]

Created attachment 385743 [details]
Patch

[youenn fablet]

Created attachment 385948 [details]
Patch

[youenn fablet]

Comment on attachment 385948 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=385948&action=review

> Source/WebCore/ChangeLog:13
> +        Previously, we were piggy backing on resuming autoplay, which happens after intteruption.

s/tt/t/

[Eric Carlson]

Comment on attachment 385948 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=385948&action=review

>> Source/WebCore/ChangeLog:13
>> +        Previously, we were piggy backing on resuming autoplay, which happens after intteruption.
> 
> s/tt/t/

s/piggy backing/piggybacking/

[youenn fablet]

Created attachment 385969 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 385969 [details]
Patch for landing

Clearing flags on attachment: 385969

Committed r253742: <https://trac.webkit.org/changeset/253742>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.