1984062 - www.boomplay.com - Unable to play songs

Status: ASSIGNED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Raul Bucata]

Environment:
Operating system: Windows 10
Firefox version: Firefox 141.0

Steps to reproduce:

1. Navigate to: https://www.boomplay.com/songs/73541059
2. Click on the "Play" button and observe

Expected Behavior:
Audio plays

Actual Behavior:
Nothing happens

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/172722

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 2

[Alice0775 White]

Console error

The resource at “https://music-205.boomplaymusic.com/group10/M00/10/21/81d7951207e3486692d8cb2b35425186.mp3?boomplay_token=exp=1755695563~acl=/group10/M00/10/21/81d7951207e3486692d8cb2b35425186.mp3~hmac=62a735460789d2f2eae272e8844639c24c9057262d1fc7905aeb802555dedc74” was blocked by OpaqueResponseBlocking. Reason: “after sniff: media request”.

A resource is blocked by OpaqueResponseBlocking, please check browser console for details. 81d7951207e3486692d8cb2b35425186.mp3

Uncaught (in promise) DOMException: The media resource indicated by the src attribute or assigned media provider object was not suitable.

Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=ad2defcb7cac84160f70c1c8646572c4c6ff4c50&tochange=b25d099d04b1d45cea1ddeda3c73a28fd5994b6e

Suspect: Bug 1762078

FYI, Setting dom.serviceWorkers.enabled to false seems to fix the issue on Nightly144.0a1 windows11.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1762078

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Artur, can you please take a look at this issue? Thank you.

Comment 5

[Artur Iunusov]

At least, in console I see that network request is simply aborted (NS_BINDING_ABORTED)
Status 403

I need to check regression range to understand, what exactly was changed in workers networking related code

await fetch("https://music-205.boomplaymusic.com/group10/M00/10/21/81d7951207e3486692d8cb2b35425186.mp3?boomplay_token=exp=1756821596~acl=/group10/M00/10/21/81d7951207e3486692d8cb2b35425186.mp3~hmac=e7ab71a68c3804f0598b88985347046f622539e466b9fdc0e08bda8e89af9bfb", { "credentials": "omit", "headers": { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:142.0) Gecko/20100101 Firefox/142.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-", "Sec-Fetch-Dest": "audio", "Sec-Fetch-Mode": "no-cors", "Sec-Fetch-Site": "cross-site", "Priority": "u=4" }, "referrer": "https://www.boomplay.com/", "method": "GET", "mode": "cors" });

Comment 6

[Artur Iunusov]

we need to implement range requests for service worker
because right now we blocking them

Comment 7

[Eden Chuang[:edenchuang]]

Hi Artur, if I remember correctly, we just fallback the range requests to the network by skipping ServiceWorker interception, so it is still worth understanding why we get a NS_BINDING_ABORTED for the request. I suppose it would be normal to encounter an error in an offline case, but according to the bug description, it appears to be an online case.

Comment 8

[Artur Iunusov]

I just reverted the changeset
in order to make this code look like:

if (!nsContentUtils::IsNonSubresourceRequest(aChannel)) {
    const Maybe<ServiceWorkerDescriptor>& controller =
        loadInfo->GetController();


     // If the controller doesn't handle fetch events, return false
    if (controller.isSome()) {
      *aShouldIntercept = controller.ref().HandlesFetch();
 
      // The service worker has no fetch event handler, try to schedule a
      // soft-update through ServiceWorkerRegistrationInfo.
      // Get ServiceWorkerRegistrationInfo by the ServiceWorkerInfo's principal
      // and scope
      if (!*aShouldIntercept && swm) {
        nsCOMPtr<nsIPrincipal> principal =
            controller.ref().GetPrincipal().unwrap();
        RefPtr<ServiceWorkerRegistrationInfo> registration =
            swm->GetRegistration(principal, controller.ref().Scope());
        // Could not get ServiceWorkerRegistration here if unregister is
        // executed before getting here.
        if (NS_WARN_IF(!registration)) {
          return NS_OK;
        }
        registration->MaybeScheduleTimeCheckAndUpdate();
       }
    } else {
      *aShouldIntercept = false;
     }

    return NS_OK;
  }

and song is playing.
So, setting aShouldIntercept to false definitely breaks something.

(I will collect a profile or/and pernosco traces to understand the cause of NS_BINDING_ABORTED)

Comment 9

[Donal Meehan [:dmeehan]]

(In reply to Artur Iunusov from comment #8)

I just reverted the changeset
in order to make this code look like:

if (!nsContentUtils::IsNonSubresourceRequest(aChannel)) {
    const Maybe<ServiceWorkerDescriptor>& controller =
        loadInfo->GetController();


     // If the controller doesn't handle fetch events, return false
    if (controller.isSome()) {
      *aShouldIntercept = controller.ref().HandlesFetch();
 
      // The service worker has no fetch event handler, try to schedule a
      // soft-update through ServiceWorkerRegistrationInfo.
      // Get ServiceWorkerRegistrationInfo by the ServiceWorkerInfo's principal
      // and scope
      if (!*aShouldIntercept && swm) {
        nsCOMPtr<nsIPrincipal> principal =
            controller.ref().GetPrincipal().unwrap();
        RefPtr<ServiceWorkerRegistrationInfo> registration =
            swm->GetRegistration(principal, controller.ref().Scope());
        // Could not get ServiceWorkerRegistration here if unregister is
        // executed before getting here.
        if (NS_WARN_IF(!registration)) {
          return NS_OK;
        }
        registration->MaybeScheduleTimeCheckAndUpdate();
       }
    } else {
      *aShouldIntercept = false;
     }

    return NS_OK;
  }

and song is playing.
So, setting aShouldIntercept to false definitely breaks something.

(I will collect a profile or/and pernosco traces to understand the cause of NS_BINDING_ABORTED)

Is there possibly a patch that we could we could ship in Fx145?

Comment 10

[Artur Iunusov]

Unfortunately, we cannot simply revert the patch
According to Eden's suggestion, we must fallback such requests to the network layer
(there is no patch so far but I'm working on it)

Comment 11

[Artur Iunusov]

Attachment: WIP: Bug 1984062 - fallback the range requests to the network layer

Comment 12

[Artur Iunusov]

In short, ORB (OpaqueResponseBlocking) blocks the request still

Comment 13

[Artur Iunusov]

Update: disabled browser.opaqueResponseBlocking in about:config
Still getting NS_BINDING_ABORTED

(sending needinfo to myself to keep track of issue)

the cause is still this patch: https://hg-edge.mozilla.org/integration/autoland/rev/47a7f8cc08213c60a6fc0c294c18b803fa69d2aa

Comment 14

[Artur Iunusov]

If disabling service workers helps,
I guess additional logic must be added there: https://searchfox.org/firefox-main/rev/4258ca077fefa5202714932d293396d2e84b58da/netwerk/protocol/http/HttpBaseChannel.cpp#4333-4335,4356-4358

Check if we have a range header, and bypass a service worker

(trying to implement and test)

Comment 15

[Artur Iunusov]

Tested. Disabled browser.opaqueResponseBlocking
So, I am getting 403 + NS_BINDING_ABORTED + message from the server "Request header x-boomplay-ref is wrong",
because the ServiceWorker turns the request into no-cors, which strips x-boomplay-ref (browser is not allowed to send it).
Reverting this patch fixes the issue, because setting aShouldIntercept to true keeps request unchanged, and therefore, it contains x-boomplay-ref header, and song is playing

Sounds like a spec issue for me.

Comment 16

[Artur Iunusov]

Basically, we are dealing with no-cors request.

When a request is created in no-cors mode, only “no-CORS-safelisted” headers are allowed.
All other headers, including "x-boomplay-ref" are removed.

According to the fetch spec:

To determine whether a header (name, value) is a no-CORS-safelisted request-header, run these steps:

1. If name is not a no-CORS-safelisted request-header name, then return false.

Therefore, in no-cors mode, response header Access-Control-Allow-Headers: x-boomplay-ref is not working intentionally

TLDR:
https://searchfox.org/firefox-main/rev/08c6e2464d7ac105490e601eec1390e6edef190b/dom/serviceworkers/ServiceWorkerInterceptController.cpp#103
aShouldIntercept = false means, no-cors (by default), request goes directly to the network, and according to the fetch spec, x-boomplay-ref header is not allowed
aShouldIntercept = true allows SW to reissue a new cross origin request (CORS). In CORS mode, custom headers are allowed if the server permits them (Access-Control-Allow-Headers: x-boomplay-ref)

I'd consider a review and soften a condition here (taking to the account this is a security patch that prevents a timing attack)
Although, being spec compliant and at the same time safe against the timing attacks - could be a tough task.

Comment 17

[Artur Iunusov]

Attachment: Bug 1984062 - Allow SW interception If the request has a controlling Service Worker that declares a fetch handler, r=edenchuang

Comment 18

[Artur Iunusov]

here is the patch that fixes playback issue and illustrates my thoughts:
https://phabricator.services.mozilla.com/D267772

Comment 19

[Artur Iunusov]

considering https://bugzilla.mozilla.org/show_bug.cgi?id=1984062#c16
I believe, the only way to fix the issue, is to implement a "hack" for that specific website.
Or consider to reviewing timing attack prevention patch, that fixes a security issue, but breaks a spec

Comment 20

[Pascal Chevrel:pascalc]

(In reply to Artur Iunusov from comment #19)

considering https://bugzilla.mozilla.org/show_bug.cgi?id=1984062#c16
I believe, the only way to fix the issue, is to implement a "hack" for that specific website.

Thomas, would a site intervention for this issue be possible? Thanks

Comment 21

[Artur Iunusov]

I think it's a good idea to invite a website developers (to fix the issue on their side)
I need to write a good explanation and ask them to refer to this thread