1792395 - Full song is not shown in spotify embeds with ETP set to STANDARD

Status: VERIFIED FIXED

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Raul Bucata]

Attachment: Screenshot_23.jpg

Environment:
Operating System: Windows 10 PRO x64

Firefox version: Firefox Nightly 107.0a1 (2022-09-25) (64-bit)

Preconditions:
ETP set to STANDARD
Clean profile
Signed in to Spotify.

Steps to reproduce:

1. Navigate to: https://jsfiddle.net/5wz6ya09/
2. Observe the embedded Spotify player.

Expected Behavior:
The full song is shown.

Actual Behavior:
The preview of the song is shown.

Notes:

• Not reproducible with ETP set to OFF.
• Reproducible in PRIVATE Mode as well.
• Screenshot attached.

Comment 1

[Tim Huang[:timhuang]]

The title suggests this is an ETP Standard breakage, but the Preconditions say that ETP needs to be set to STRICT. Could you clarify if this is an ETP strict breakage? Thanks.

Comment 2

[Raul Bucata]

Sorry about that Tim, my mistake. I did not encounter an ETP STANDARD issue for a while, so by force of habit, I left the precondition to STRICT. I have updated the precondition accordingly.

Comment 3

[08xjcec48]

Please correct the title of this issue. It's not about jsfiddle.net specifically but about Spotify iframes on third-party sites in general.

Comment 4

[Raul Bucata]

Thanks for the update, Andre. This info will be taken into consideration by our development team.

Comment 5

[Emma Zühlcke [:emz]]

The Spotify embed can't get your login status, because it can't access it's first-party cookie jar in the embedded context. They could use the Storage Access API to request storage access, e.g. when the user clicks on play. They could also add an interstitial view that asks users to click to login.

A shim in Firefox could request storage access on click of the play button and then reload the frame when it is granted storage access - in order to update the UI to reflect the login state. I'll look into it.

Comment 6

[Emma Zühlcke [:emz]]

Attachment: Bug 1792395 - Add a Spotify embed dFPI shim.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a45679383e39
Add a Spotify embed dFPI shim. r=webcompat-reviewers,twisniewski

Comment 8

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/a45679383e39

Comment 9

[Emma Zühlcke [:emz]]

To clarify: The shim does not fully address the breakage in that the full UI is not shown on load, it is only shown after the user clicks the play button. The user interaction is a requirement for requesting storage access.

Comment 10

[Emma Zühlcke [:emz]]

I've notified Spotify of the breakage via email.

Comment 11

[Pascal Chevrel:pascalc]

Paul, should we uplift that patch to beta 110? Thanks

Comment 12

[Emma Zühlcke [:emz]]

Since it's only partial breakage and a workaround exists I'd rather not. I'd also like to give this shim some more bake time in Nightly. Thanks!

Comment 13

[Rares Doghi, Desktop QA]

Hi @Paul, I tried to verify the fix on this issue but after logging in to Spotify and reaching the JsFiddle page after hitting the Play button and Reloading the frame it would still show the Preview for the song and not the entire song.

Also when I hit the Play button on the JS Fiddle page im getting this error message in Storage: document.requestStorageAccess() may not be called in a sandboxed iframe without allow-storage-access-by-user-activation in its sandbox attribute.

Am I missing something ? how can I verify the fix on this issue ?

Comment 14

[Emma Zühlcke [:emz]]

Make sure to test with https://deluxe-relieved-tent.glitch.me, the other test sites given may have sandboxing enabled as part of their editor.

Comment 15

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

Your demo only partially works on my machine. Is the following situation expected?

1. I click the first iframe's play button
2. It reloads automatically after requesting storage access
3. But it still loads with "PREVIEW" mark on it. (Sometimes it does load with a full song at this step, so it's kinda a lottery.)
4. Reloading each frame does not help.
5. I reload the whole page
6. Then I get the full songs for all frames.

It's worse in sandboxed example as step 5 doesn't help either: https://diligent-guttural-earwig.glitch.me/.

Comment 16

[Rares Doghi, Desktop QA]

I was able to verify the fix in our latest Nightly Build 112.0a1 (2023-03-12).
In our latest RC build 111.0 the "Deep House Blend" iframe would sometimes need 2 reloads after Hitting the play button in order for the Preview tag to disappear.

Other Frames would only need 1 reload.
Please note that In Nightly the frame would auto reload after the play button is clicked.

@Paul is it ok that sometimes it needs a second reload in order to work ? if so we can mark 111.0 with Verified as well.

Comment 17

[Emma Zühlcke [:emz]]

Only Bug 1820212 added supports for the remaining embed types so the behavior you're observing in Fx111 is expected. In Fx112 the shim should apply to all types on that page which have a "preview" state initially.

Comment 18

[Emma Zühlcke [:emz]]

(In reply to Kagami [:saschanaz] from comment #15)

Your demo only partially works on my machine. Is the following situation expected?

1. I click the first iframe's play button
2. It reloads automatically after requesting storage access
3. But it still loads with "PREVIEW" mark on it. (Sometimes it does load with a full song at this step, so it's kinda a lottery.)
4. Reloading each frame does not help.
5. I reload the whole page
6. Then I get the full songs for all frames.

It's worse in sandboxed example as step 5 doesn't help either: https://diligent-guttural-earwig.glitch.me/.

Which version did you test this with? I can't reproduce this problem on Nightly. The result for sandbox is expected as the shim does not support it. We would have to add the storage access API sandbox flag in order to fix that.

Comment 19

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

On the latest Nightly build at that day, but somehow it works as expected on today's Nightly with and without sandbox. So I'm now happy!

The result for sandbox is expected as the shim does not support it. We would have to add the storage access API sandbox flag in order to fix that.

That's weird, I think it works?

Comment 20

[Emma Zühlcke [:emz]]

(In reply to Kagami [:saschanaz] from comment #19)

On the latest Nightly build at that day, but somehow it works as expected on today's Nightly with and without sandbox. So I'm now happy!

The result for sandbox is expected as the shim does not support it. We would have to add the storage access API sandbox flag in order to fix that.

That's weird, I think it works?

The iframes on the page you linked have allow-storage-access-by-user-activation set, that's why it works.

Comment 21

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

(In reply to Paul Zühlcke [:pbz] from comment #20)

The iframes on the page you linked have allow-storage-access-by-user-activation set, that's why it works.

👍

Comment 22

[Rares Doghi, Desktop QA]

Verified as fixed in Firefox 111.0

Comment 23

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

Hmm, turns out it still happens on my mac, with the same behavior I observed in comment #15.

Interestingly, the reload happens with some delay when working, while it happens almost immediately after click when not working. Perhaps there's some bug in the Storage Access API?

I can bring this machine next week, if that helps.

Comment 24

[Emma Zühlcke [:emz]]

Apologies, I haven't really had time to look into this more. The shim does have a few issues, so I'm hoping we can just remove it once Spotify fixes the embeds to work with 3rd-party partitioned cookies.

Comment 25

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

That's completely fine to me, I just wonder the fault is in the Storage Access API somehow not granting the access properly.