1992709 - open.spotify.com - Album and playlist covers missing in search results when logged in on desktop site using a tablet device

Status: NEW

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

Description

[Raul Bucata]

Environment:
Operating system: Android 12
Firefox version: Firefox Mobile 143.0

Preconditions:

• Tablet device used
• Desktop mode enabled for page

Steps to reproduce:

1. Navigate to: https://open.spotify.com
2. Perform account login
3. Search for a band with an album and observe

Expected Behavior:
Album cover is present

Actual Behavior:
Album covers and playlists missing in context menu when logged in on desktop site (service worker issue)

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/179643

Comment 1

[Raul Bucata]

Attachment: Chr vs FF Tablet

Comment 2

[Raul Bucata]

Does not reproduce on mobile devices, in mobile view when using a tablet, or when logged out.

Comment 3

[Raul Bucata]

Attachment: desktop mode tablet device

Comment 4

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

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

Comment 5

[Kagami Rosylight [:saschanaz] (they/them)]

What tablet is used here? Is it still happening? What is the user agent string? Is the same happening when the same user agent string is used in desktop in devtools mobile emulation mode? I don't have a tablet device to test, so I need some help 🙏🏻

Comment 6

[Raul Bucata]

It's a Samsung Tab S6 (Android 12) - 1600x2560 pixels, 16:10 ratio (~287 ppi density). I still get the issue. It seems to be specific to a real device, as I can't really find a UA String to reproduce in RDM.

Comment 7

[Kagami Rosylight [:saschanaz] (they/them)]

Can confirm on Pixel Tablet, thanks.

Comment 8

[Kagami Rosylight [:saschanaz] (they/them)]

A bunch of NS_ERROR_INTERCEPTION_FAILED in network log for images which is a service worker error.

Comment 9

[Kagami Rosylight [:saschanaz] (they/them)]

SW interception is failing because fetch is failing there. The SW code is same, but somehow it only fails on Android?

https://open.spotify.com/service-worker.js

        try {
          let e;
          e = await fetch(r, 'navigate' === r.mode ? void 0 : this._strategy.fetchOptions);
          for (const r of this.iterateCallbacks('fetchDidSucceed')) e = await r({
            event: t,
            request: a,
            response: e
          });
          return e
        } catch (i) {
          throw n &&
          await this.runCallbacks(
            'fetchDidFail',
            {
              error: i,
              event: t,
              originalRequest: n.clone(),
              request: a.clone()
            }
          ),
          i
        }

Here the request looks like:

Request {
  method: "GET",
  url: "https://i.scdn.co/image/ab67616d0000485138ada58497693555e12bee30",
  headers: Headers,
  destination: "image",
  referrer: "https://open.spotify.com/",
  referrerPolicy: "strict-origin-when-cross-origin",
  mode: "no-cors",
  credentials: "include",
  cache: "default",
  redirect: "follow"
}

And the fetch option is:

{ credentials: "omit", mode: "cors" }

Somehow CORS mode and destination: "image" doesn't seem to play along on Android. If I copy all the request options except destination (which I can't set from JS after all) and pass that, or if I omit the mode option, then the fetch succeeds.

So I think this is something in fetch side. But before passing it to networking, NI'ing Eden in case I'm missing anything.

Comment 10

[Eden Chuang[:edenchuang]]

The requestMode is set when Fetch request is constructed
https://searchfox.org/firefox-main/rev/5ffe434ed799aa243e54a264b94e4946fc792d59/dom/fetch/Request.cpp#190-197,206-209,223-225,318-320

But when the request should be intercepted by a ServiceWorker, we re-create the request from InterceptedHttpChannel for FetchEvent dispatching.
https://searchfox.org/firefox-main/rev/5ffe434ed799aa243e54a264b94e4946fc792d59/dom/serviceworkers/ServiceWorkerPrivate.cpp#329-330
And we re-compute the requestMode here
https://searchfox.org/firefox-main/rev/5ffe434ed799aa243e54a264b94e4946fc792d59/dom/fetch/InternalRequest.cpp#474-507

I guess the logic for requestMode computing might have a problem on the Android platform.

Kagami, could you add some checking on the Fetch request construction and requestMode computing to check if the requestModes are matched? And also checking them both in Android and Desktop to see if computing in Android platform get wrong?

Comment 11

[Kagami Rosylight [:saschanaz] (they/them)]

I'm on it, but am I understanding correctly that this re-compute is about the SW-side fetch during the interception rather than content-side fetch being intercepted?

Comment 12

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: WIP: Bug 1992709 - Add profile markers for investigation

Comment 13

[Eden Chuang[:edenchuang]]

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #11)

I'm on it, but am I understanding correctly that this re-compute is about the SW-side fetch during the interception rather than content-side fetch being intercepted?

Yes, your understanding is correct. The recompute one is for FetchEvent.request, the request sent to the ServiceWorker fetch event handler.

Comment 14

[Kagami Rosylight [:saschanaz] (they/them)]

I see Request::Constructor in child process always setting "cors" on desktop/android (even though the request in SW is "no-cors"). From the parent process I see some requests with security mode 16 being cors, or mode 4 being no-cors. Unclear which request is from which though, probably needs better logging for that.

Note that the requests are from HTML image element, I'm not sure it's using Fetch API internally at all, so I'm not sure what we are expecting by adding logs on Request constructor.

Interestingly, calling fetch in SW via devtools with the intercepted request doesn't trigger any of the added logs.