Steps to reproduce the issue 1. use a iPhone X with iOS 12.1 2. Go on the test page in Safari and trigger play (unmuted) 3. Wait for a second, then swipe at the bottom of the screen to switch to a different app, e.g. Notes app 4. Wait for a second, then swipe back to Safari 5. Repeat steps 3 and 4 until the error is thrown (takes somewhat from 3 to 20 tries) Code to reproduce: <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> </head> <body> <video src="https://bitmovin-a.akamaihd.net/content/MI201109210084_1/m3u8s/f08e80da-bf1d-4e3d-8899-f0f6155f6efa.m3u8" autoplay controls style="width: 100%; height: 60%;"></video> <div id="error"></div> <script type="text/javascript"> document.querySelector('video').addEventListener('error', function(e) { alert('Video element threw error code ' + e.srcElement.error.code); }); </script> </body> </html>
<rdar://problem/48745141>
Hi, We noticed a similar behaviour on our side (dailymotion) on iOS 12.2 (Safari version 12.1). We tried on many devices: iPhone 6s, iPhone 7 plus, iPhone Xmax with the same result. The issue happens not only when you switch to a different app, but even when you lock-unlock the screen, therefore it looks like a behaviour related to a document visibilitychange event. If we manually reload the stream on visibilitychange (when the user returns to the page), the bug does not happen. Are there any updates on this?
Hi, We've also been able to reproduce the issue at JW Player, and have received bug reports from publishers using our player. As a workaround we're handling decode errors that fire after playback on iOS by calling mediaElement.load() and setting currentTime to the last known value. Not ideal, but absolutely necessary, as MediaErrors are typically treated as fatal player errors, and we don't want users coming back to a page to find the video player in an error state.
Eric adopted some new API in r245039 which should help with these kinds of errors. I can ping the thread once that change is available in a public beta on iOS and DailyMotion and JW Player can verify that this indeed fixes this issue.
The underlying issue: when Safari is in the background, it can get suspended by the system. In the suspended state, it can't respond to requests from AVFoundation to reload the manifest, and AVFoundation responds by firing an error at the media element. Some of this behavior was reduced by trac.webkit.org/r242113 and trac.webkit.org/r243958, and Eric's patch should take care of the rest.
And this comment chain reminds me that we need to update our Bugzilla plugin to turn r[[:digit:]]{5,} text into trac.webkit.org links. :-/
Hi Jer, any news regarding date for a fix? issue happens to Kaltura as well and for some reason after we applied an internal handling as a workarounbd the issue now came back so wondering if there is some additional regression here from lately.