221413 2021-02-04 09:12:13 -0800 Safari does not execute JavaScript code to play another audio item when playing backgrounded FairPlay content 2022-12-16 12:01:25 -0800 1 1 1 Unclassified WebKit Web Audio Safari 14 iPhone / iPad iOS 14 NEW https://bugs.webkit.org/show_bug.cgi?id=233257 InRadar P2 Normal --- 1 thomass webkit-unassigned brad cdumez jer.noble supersonicandtails webkit-bug-importer xyeres oldest_to_newest 1725649 0 thomass 2021-02-04 09:12:13 -0800 Hello, we are currently attempting to get Safari to automatically move on to the next audio track when a track ends (by subscribing to the "ended" event of the media element), when the browser is in the background. We are doing this by executing JavaScript that replaces the src attribute with a new HLS manifest URL. Currently playback terminates at the end of the first track and does not progress to the second. No error is raised. The expected behaviour would be that playback continues with the next audio track. Could you assist? 1726491 1 ap 2021-02-07 10:51:23 -0800 Tba kn you for the report! Could you please provide a test case? 1727039 2 thomass 2021-02-09 07:18:32 -0800 (In reply to Alexey Proskuryakov from comment #1) > Thank you for the report! Could you please provide a test case? Reproduction steps 1. Open Safari on an iOS device 2. Go to URL: https://spoti.fi/harmony-doctor 3. Log in with a Spotify user. 4. Start playback on a playlist, album, or other context with multiple tracks. 5. Wait for playback to start 6. Background Safari 7. Wait for the first song to end Expected outcome The second song should play Actual outcome Playback stop 1728125 3 webkit-bug-importer 2021-02-11 09:13:14 -0800 <rdar://problem/74236954> 1867342 4 458973 brad 2022-05-06 14:17:23 -0700 Created attachment 458973 Demonstrates the bug in iOS Safari This bug is still an issue, and is also a problem for regular audio files without DRM. Attached is a page with some script demonstrating the issue. Observations: - The `ended` event does fire and its handlers do run, even when the screen is off. - Upon replacing the `src` of the `<audio>` element, it cannot be played via script when the screen is off. - The `paused` property value is `false`, `currentTime` is `0` zero. Audio playback does not occur. - The only way to resume playback is to unlock phone, and use a UI element to call `.play()` on the audio element. This prevents web apps from playing from a playlist of media. It also seems to be a regression, as this method used to work. This method is also documented here: https://developer.apple.com/library/archive/documentation/AudioVideo/Conceptual/Using_HTML5_Audio_Video/ControllingMediaWithJavaScript/ControllingMediaWithJavaScript.html#//apple_ref/doc/uid/TP40009523-CH3-SW5 1902640 5 supersonicandtails 2022-10-01 14:16:57 -0700 (In reply to Brad Isbell from comment #4) > Created attachment 458973 [details] > Demonstrates the bug in iOS Safari > > This bug is still an issue, and is also a problem for regular audio files > without DRM. > > Attached is a page with some script demonstrating the issue. > > Observations: > > - The `ended` event does fire and its handlers do run, even when the screen > is off. > - Upon replacing the `src` of the `<audio>` element, it cannot be played > via script when the screen is off. > - The `paused` property value is `false`, `currentTime` is `0` zero. Audio > playback does not occur. > - The only way to resume playback is to unlock phone, and use a UI element > to call `.play()` on the audio element. > > This prevents web apps from playing from a playlist of media. It also seems > to be a regression, as this method used to work. This method is also > documented here: > https://developer.apple.com/library/archive/documentation/AudioVideo/ > Conceptual/Using_HTML5_Audio_Video/ControllingMediaWithJavaScript/ > ControllingMediaWithJavaScript.html#//apple_ref/doc/uid/TP40009523-CH3-SW5 Brad, are you doing any potentially long-running async operations (fetch, etc.) before the next track starts playing? I have this use case working in my own app. Playback of a user playlist works continuously with the Safari browser tab backgrounded on desktop, or PWA backgrounded on iOS. 1920023 6 xyeres 2022-12-16 12:01:25 -0800 I have been searching for a solution to this for the past 11 months, as Tom stated, all of my attempts to replace a media (<audio>) source sequentially while in the background (or in locked screen) have failed until recently when I updated iOS. The issue appears to have been fixed. I made no code changes to my app and it just began working after updating to iOS 15.7.2 (The fix may have been prior to this particular version however since I was on 15.5x) I've tried to look for more information in the release notes but haven't been able to spot the exact change that resolved this issue. Very happy about this fix. 458973 2022-05-06 14:17:23 -0700 2022-05-06 14:17:23 -0700 Demonstrates the bug in iOS Safari alt-test.html text/html 1911 brad PCFET0NUWVBFIGh0bWw+CjxodG1sPgogIDxoZWFkPgogICAgPG1ldGEgY2hhcnNldD0iVVRGLTgi IC8+CiAgICA8dGl0bGU+aU9TIFNhZmFyaSBTZXF1ZW50aWFsIE1lZGlhIEJ1ZyBUZXN0PC90aXRs ZT4KICAgIDxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lkdGgs IGluaXRpYWwtc2NhbGU9MSIgLz4KICAgIDxzY3JpcHQgdHlwZT0ibW9kdWxlIj4KICAgICAgY29u c3QgdXJscyA9IFsKICAgICAgICAnaHR0cHM6Ly9hcmNoaXZlLm9yZy9kb3dubG9hZC9jZF90aGUt bmV3LWRlYWxfdGhlLW5ldy1kZWFsL2Rpc2MxLzAxLiUyMFRoZSUyME5ldyUyMERlYWwlMjAtJTIw QmFjayUyMHRvJTIwdGhlJTIwTWlkZGxlX3NhbXBsZS5tcDMnLAogICAgICAgICdodHRwczovL2Fy Y2hpdmUub3JnL2Rvd25sb2FkL2NkX3RoZS1uZXctZGVhbF90aGUtbmV3LWRlYWwvZGlzYzEvMDIu JTIwVGhlJTIwTmV3JTIwRGVhbCUyMC0lMjBSZWNlaXZlcl9zYW1wbGUubXAzJywKICAgICAgICAn aHR0cHM6Ly9hcmNoaXZlLm9yZy9kb3dubG9hZC9jZF90aGUtbmV3LWRlYWxfdGhlLW5ldy1kZWFs L2Rpc2MxLzAzLiUyMFRoZSUyME5ldyUyMERlYWwlMjAtJTIwRXhjaXRpbmclMjBOZXclMjBEaXJl Y3Rpb25fc2FtcGxlLm1wMycsCiAgICAgICAgJ2h0dHBzOi8vYXJjaGl2ZS5vcmcvZG93bmxvYWQv Y2RfdGhlLW5ldy1kZWFsX3RoZS1uZXctZGVhbC9kaXNjMS8wNC4lMjBUaGUlMjBOZXclMjBEZWFs JTIwLSUyMFNlbGYlMjBPcmJpdF9zYW1wbGUubXAzJwogICAgICBdOwoKICAgICAgY29uc3QgYXVk aW8gPSBkb2N1bWVudC5xdWVyeVNlbGVjdG9yKCdhdWRpbycpOwoKICAgICAgZnVuY3Rpb24gbmV4 dCgpIHsKICAgICAgICBhdWRpby5zcmMgPSB1cmxzLnBvcCgpOwogICAgICAgIGF1ZGlvLnBsYXko KTsKICAgICAgfQoKICAgICAgYXVkaW8uYWRkRXZlbnRMaXN0ZW5lcignZW5kZWQnLCBuZXh0KTsK CiAgICAgIGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3IoJ2J1dHRvbicpLmFkZEV2ZW50TGlzdGVuZXIo J2NsaWNrJywgbmV4dCk7CiAgICA8L3NjcmlwdD4KICAgIDxzdHlsZT4KICAgICAgYnV0dG9uIHsK ICAgICAgICBkaXNwbGF5OiBibG9jazsKICAgICAgICBmb250LXNpemU6IGluaGVyaXQ7CiAgICAg IH0KICAgIDwvc3R5bGU+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPGgxPmlPUyBTYWZhcmkgU2Vx dWVudGlhbCBNZWRpYSBCdWcgVGVzdDwvaDE+CiAgICA8aDI+SW5zdHJ1Y3Rpb25zPC9oMj4KICAg IDxwPgogICAgICA8b2w+CiAgICAgICAgPGxpPkNsaWNrL1RhcCAnU3RhcnQvTmV4dCcuPC9saT4K ICAgICAgICA8bGk+RW5qb3kgdGhlIG11c2ljLjwvbGk+CiAgICAgICAgPGxpPk9ic2VydmUgdGhh dCBhZnRlciBhIHR1bmUgaXMgb3ZlciwgdGhlIG5leHQgd2lsbCBhdXRvbWF0aWNhbGx5IGJlIGxv YWRlZC48L2xpPgogICAgICAgIDxsaT5Ob3csIGluIHRoZSBtaWRkbGUgb2YgdHVuZSwgdHVybiBv ZmYgdGhlIHBob25lIHNjcmVlbi48L2xpPgogICAgICAgIDxsaT5PYnNlcnZlIHRoYXQgYWZ0ZXIg YSB0dW5lIGlzIG92ZXIsIHRoZSBuZXh0IGlzIDxlbT5ub3Q8L2VtPiBhdXRvbWF0aWNhbGx5IGJl IGxvYWRlZC48L2xpPgogICAgICAgIDxsaT5CZSBzYWQgdGhhdCB0aGlzIGJ1ZyBoYXMgcHJldmVu dGVkIHlvdSBmcm9tIGVuam95aW5nIHRoZSBtdXNpYy48L2xpPgogICAgICA8L29sPgogICAgPC9w PgogICAgPHA+Tm90ZTogVGhlcmUgYXJlIDQgbWVkaWEgaXRlbXMgbG9hZGVkIGJ5IHRoaXMgdGVz dC4gIEVkaXQgdGhpcyBmaWxlIHRvIGFkZCBtb3JlIGlmIHlvdSB3aXNoLjwvcD4KICAgIDxoMj5U ZXN0PC9oMj4KICAgIDxidXR0b24+U3RhcnQvTmV4dDwvYnV0dG9uPgogICAgPGF1ZGlvIGNvbnRy b2xzPjwvYXVkaW8+CiAgPC9ib2R5Pgo8L2h0bWw+