Open Bug 1926488 Opened 1 year ago Updated 3 months ago

mail.google.com - Unable to play videos sent via chat with Standard ETP

Categories

(Web Compatibility :: Privacy: Site Reports, defect, P2)

Firefox 133
Desktop
Windows 10

Tracking

(firefox131 affected, firefox133 affected)

Tracking Status
firefox131 --- affected
firefox133 --- affected

People

(Reporter: ctanase, Unassigned)

References

(Blocks 3 open bugs, )

Details

(Keywords: priv-webcompat, webcompat:tracker-blocking)

Attachments

(2 files)

Environment:
Operating system: Windows 10
Firefox version: 131/133

Preconditions:
• ETP set to STANDARD
• Must be logged in
• Download the sample video provided in attachments

Steps to reproduce:

  1. Go to https://mail.google.com
  2. Open a chat with anybody.
  3. Upload the provided video in the chat.
  4. Wait for the upload to be completed.
  5. Click on the video and try to play it.

Expected Behavior:
The video can be played.

Actual Behavior:
The video does not play.

Notes:

  1. Screen rec attached
  2. Reproducible with Standard and Strict ETP
  3. Does not reproduce with ETP turned OFF
  4. Same behavior in Private mode
  5. Not reproducible on Chrome

Could you take a closer look please?

Flags: needinfo?(lschwarz)
Severity: -- → S3
Keywords: priv-webcompat
Priority: -- → P1

Hi, this is caused by TCP / a third-paryt cookie missing. This is also broken in Chrome with third-party cookie blocking enabled.

Flags: needinfo?(lschwarz) → needinfo?(dmehic)
Flags: needinfo?(dmehic)
Severity: S3 → S2
Priority: P1 → P2

This is actually a TCP issue but not a 3PCD issue. The video starts to place if I disabled TCP regardless of 3PCD.

Blocks: dfpi-breakage
No longer blocks: 3pcd-breakage

Sorry, it's actually also a 3PCD issue. We also disable 3PCD if TCP is disabled, so I misunderstood the issue.

No longer blocks: dfpi-breakage

Seeing if we can shim this. Surprisingly this works in Safari.

Assignee: nobody → emz
Status: NEW → ASSIGNED

Ok so this is the embed hierarchy:

https://mail.google.com -> https://chat.google.com (iframe) -> https://youtube.googleapis.com (iframe) -> https://chat.google.com (video element src)

We can temporarily allowlist this pair: https://mail.google.com,https://chat.google.com. I have not found an easy way to shim this yet, but I'll keep looking.

Blocks: 1970377

This seems tricky to shim, because the inner most origin is the video src itself, so it can't call the storage access API. The upcoming Storage Access Headers feature may help here. I'll reach out to Google to see if they can fix this issue.

Lowering severity and unassigning now that an intervention is deployed. In the meantime I've reached out to Google and I'm waiting to hear back.

Assignee: emz → nobody
Severity: S2 → S3
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: