[Webkit-unassigned] [Bug 204681] New: Audio track goes to readyState ended when Safari is backgrounded for more than 30 seconds

[bugzilla-daemon at webkit.org]

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

            Bug ID: 204681
           Summary: Audio track goes to readyState ended when Safari is
                    backgrounded for more than 30 seconds
           Product: WebKit
           Version: Safari 13
          Hardware: iPhone / iPad
                OS: iOS 13
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebRTC
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: daginge at confrere.com
                CC: youennf at gmail.com

Created attachment 384455

  --> https://bugs.webkit.org/attachment.cgi?id=384455&action=review

Screenshot showing the issue on an iPhone X running iOS 13.2.3

Summary:
If a web page capturing audio is backgrounded for more than 30 seconds the audio track's readyState goes to "ended". This does not affect the video track. The audio track is now useless until you refresh the page or call getUserMedia again. Sometimes the video track will end as well, there seems to be some kind of difference in the background kill rate for these two resources.

Steps to reproduce:
1. Go to https://codepen.io/daginge/full/XWWvBbe on an iPhone running iOS 13.2.3
2. Tap: "Start"
3. Observe that video is now working, and the system logs as expected. You should also be able to hear yourself.
4. Go to the home screen, and stay there for at least 30 seconds, sometimes 5-6 seconds more.
5. Open Safari again
6. Observe that the audio track's readyState is now "ended".

Sometimes both video and audio will end. Calling getUserMedia again fixes the issue.

Expected behaviour:
If a page is capturing, don't background/clean up the Safari process so that it looses media access. I would expect once media access is granted that the device does not go to sleep or kill the process until the media access is cleanly shut down.

Impact:
Pages implementing some kind of waiting room functionality, or pages where a user might go to the home screen to do a task, then come back.

Workaround:
It seems using the Page Visibility API to trigger getUserMedia again works. If you are in a call you need to use replaceTrack to get the audio and video flowing again. Refreshing the page also works.

-- 
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/20191128/cadca27a/attachment.htm>