Created attachment 470859 [details] HTMLMediaElement Events on Load When using a `src` URL without a file extension (e.g., `https://example.com/sample`) on an `<audio>` element, calling `load()` (https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/load) produces unexpected event behavior, like the `suspend` event being fired after `loadstart`, as well as the events `loadeddata`, `canplay`, and `canplaythrough` never firing. I am able to reproduce this consistently in iOS, but not macOS (both using Safari 17.4.1). This was tested by creating a Bun server that serves the same mp3 file on routes `/sample` and `/sample.mp3`. Both routes used as the `src` URL on `<audio>` elements emit the same events on macOS Safari, but in iOS Safari, `/sample` produces the irregular event behavior described above. Screenshot attached.
A demonstration will be available here until the issue is resolved: https://html-starter-six-swart.vercel.app/ This app renders the audio elements to the DOM for `/sample.mp3` and `/sample`. You'll noticed that the `/sample` src never emits a `canplay` event in Safari running on iOS 17.4, but it does in any other context like on iOS <=17.3 and macOS.
Oops, that URL for the demo app should work, but it was recently renamed to: https://webkit-audio-test.vercel.app/
<rdar://problem/126377772>
(In reply to Joseph Gomez from comment #1) > A demonstration will be available here until the issue is resolved: > https://html-starter-six-swart.vercel.app/ > > This app renders the audio elements to the DOM for `/sample.mp3` and > `/sample`. > > You'll noticed that the `/sample` src never emits a `canplay` event in > Safari running on iOS 17.4, but it does in any other context like on iOS > <=17.3 and macOS. This gives ``` 404: NOT_FOUND Code: DEPLOYMENT_NOT_FOUND ID: syd1::jfl9k-1713179201121-c5f7a8f6abd6 ```
likely related to bug 245428; which is resolved in 17.5
confirmed. On 17.5, events for /sample or /sample.mp3 are the same. *** This bug has been marked as a duplicate of bug 245428 ***
I should add. Relying on the `suspend` event to be fired in a given order according to the events related to the `readyState` attribute will likely result to an incorrect implementation (that is not per HTML5 spec) the `suspend` event is dependent on the `networkState` all `loadedmetadata` `loadeddata` `canplay` `canplaythrough` are related to `readyState` they aren't related to one another. By relying on the suspend event to be fired at a particular time, you are making your code fragile and implementation and/or network dependent. suspend just indicates that the video element has stopped fetching content (which could be momentary). On Chrome, `suspend` is typically fired right after `loadstart`, but can be after loadedmetadata In Firefox, suspend is fired in a similar fashion That Safari fires it more consistently after `loadedmetadata` is purely coincidental. I mention this according to the bug description. Per the screen capture attached, it seems that the bug was about `loadeddata` not being fired.