Closed Bug 1792395 Opened 1 year ago Closed 1 year ago

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

Categories

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

Firefox 107
Desktop
Windows
defect

Tracking

()

VERIFIED FIXED
111 Branch
Tracking Status
firefox107 --- wontfix
firefox109 --- wontfix
firefox110 --- wontfix
firefox111 --- verified
firefox112 --- verified

People

(Reporter: rbucata, Assigned: pbz)

References

(Blocks 1 open bug, )

Details

Attachments

(2 files)

Attached image 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.

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.

Flags: needinfo?(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.

Flags: needinfo?(raul.bucata)

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

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

Blocks: dfpi-breakage
No longer blocks: etp-breakage
Severity: -- → S3
Summary: Full song is not shown at jsfiddle.net with ETP set to STANDARD → Full song is not shown in spotify embeds with ETP set to STANDARD
Flags: needinfo?(pbz)

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.

Assignee: nobody → pbz
Status: NEW → ASSIGNED
Flags: needinfo?(pbz)
Attachment #9312645 - Attachment description: WIP: Bug 1792395 - Spotify embed dFPI shim. → WIP: Bug 1792395 - Add a Spotify embed dFPI shim.
Attachment #9312645 - Attachment description: WIP: Bug 1792395 - Add a Spotify embed dFPI shim. → Bug 1792395 - Add a Spotify embed dFPI shim.
Pushed by pzuhlcke@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a45679383e39
Add a Spotify embed dFPI shim. r=webcompat-reviewers,twisniewski
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 111 Branch

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.

I've notified Spotify of the breakage via email.

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

Flags: needinfo?(pbz)

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!

Flags: qe-verify+
Blocks: 1820212

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 ?

Flags: needinfo?(pbz)

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.

Flags: needinfo?(pbz)

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

Flags: needinfo?(pbz)

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.

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.

Flags: needinfo?(pbz)

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

Flags: needinfo?(krosylight)

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?

Flags: needinfo?(krosylight)

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

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

👍

Verified as fixed in Firefox 111.0

Status: RESOLVED → VERIFIED
Flags: qe-verify+

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.

Flags: needinfo?(pbz)

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.

Flags: needinfo?(pbz)

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

See Also: → 1860957
You need to log in before you can comment on or make changes to this bug.