Bug 272502 – REGRESSION (iOS 17.4): Irregular HTMLMediaElement events for src URLs without file extensions

• Component: Media
• Status: RESOLVED DUPLICATE

[Joseph Gomez]

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.

[Joseph Gomez]

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.

[Joseph Gomez]

Oops, that URL for the demo app should work, but it was recently renamed to:
https://webkit-audio-test.vercel.app/

[Radar WebKit Bug Importer]

<rdar://problem/126377772>

[Jean-Yves Avenard [:jya]]

(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
```

[Jean-Yves Avenard [:jya]]

likely related to bug 245428; which is resolved in 17.5

[Jean-Yves Avenard [:jya]]

confirmed.

On 17.5, events for /sample or /sample.mp3 are the same.

*** This bug has been marked as a duplicate of bug 245428 ***

[Jean-Yves Avenard [:jya]]

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.