User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0

Steps to reproduce:

I have a service worker with fetch event.

Actual results:

I noticed that the fetch event is firing for all fetch requests, but is no longer firing for html audio.

Expected results:

Event should have fired for html5 audio as it used to (it does work for example with Firefox 106.5)

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Correction: It is working on Firefox 106.0.5. Does not work for 107.0.1

If the audio resource is cross-origin, then this was an intentional change for bug 1762078.

With bug 1465074 and bug 1733981 open, "fetch" events were of limited value for HTMLMediaElement, though they might plausibly have still been useful for short audio elements in some situations because non-range 200 OK responses were accepted.

HTMLMediaElement provides fallback mechanisms through the source element.

Do you know whether the "fetch" event was supporting a use case that could not be similarly supported through source elements?

:jmarshall, since you are the author of the regressor, bug 1762078, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Hi,
Is there any update or progress with this item?
Thanks!

:ewolfman, is this audio resource cross-origin/no-cors? If so, this was an intentional change as :karlt described above (see bug 1762078).

Hi,
It is cross-origin but CORS is enabled and I do see CORS headers returning in the response.
I am using HTMLAudioElement 'src' attribute. When looking at 'crossOrigin' I can see it is 'null'.

In Browser Box i can see the following request/response (note the response cors headers):

GET /media/4087a753-ec46-4341-8e87-eae5569ec3d6 HTTP/2
Host: <masked>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0
Accept: audio/webm,audio/ogg,audio/wav,audio/;q=0.9,application/ogg;q=0.7,video/;q=0.6,/;q=0.5
Accept-Language: en-US,en;q=0.5
Range: bytes=0-
Connection: keep-alive
Referer: <masked>
Cookie: <masked>
Sec-Fetch-Dest: audio
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-site
Accept-Encoding: identity
TE: trailers

HTTP/2 200 OK
content-disposition: attachment;filename="b5726aa5-96bd-4294-9341-0ee12e63a438.wav"
access-control-allow-methods: POST,GET,OPTIONS
access-control-allow-origin: *
access-control-allow-headers: Content-Type
content-type: application/octet-stream
date: Thu, 15 Dec 2022 10:22:10 GMT
x-envoy-upstream-service-time: 97
server: envoy
X-Firefox-Spdy: h2

I tried changing crossOrigin to 'use-credentials' and I think it is working now (I also see the OPTIONS request now in Browser Toolbox).
Will perform some more tests.

If there is a different and better way to add 'authorization' header to html audio other than using a Service Worker (without having to fetch all the audio first) - I would gladly switch to it. Is there such a way?

Your request has a "Sec-Fetch-Mode: no-cors" header. Are you able to post your reproduction steps?

After adding crossOrigin='use-credentials' the request looks like this (and it is working well):

GET /media/1ffc8ae5-8c5d-4b3a-b233-90a47775d449 HTTP/2
Host: <masked>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0
Accept: /
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: <masked>
Authorization: Bearer <masked>
Origin: <masked>
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
TE: trailers

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.