mail.google.com - Unable to play videos sent via chat with Standard ETP
Categories
(Web Compatibility :: Privacy: Site Reports, defect, P2)
Tracking
(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:
- Go to https://mail.google.com
- Open a chat with anybody.
- Upload the provided video in the chat.
- Wait for the upload to be completed.
- Click on the video and try to play it.
Expected Behavior:
The video can be played.
Actual Behavior:
The video does not play.
Notes:
- Screen rec attached
- Reproducible with Standard and Strict ETP
- Does not reproduce with ETP turned OFF
- Same behavior in Private mode
- Not reproducible on Chrome
Reporter | ||
Comment 1•1 year ago
|
||
Comment 3•1 year ago
|
||
Hi, this is caused by TCP / a third-paryt cookie missing. This is also broken in Chrome with third-party cookie blocking enabled.
Comment 4•8 months ago
|
||
This is actually a TCP issue but not a 3PCD issue. The video starts to place if I disabled TCP regardless of 3PCD.
Comment 5•8 months ago
|
||
Sorry, it's actually also a 3PCD issue. We also disable 3PCD if TCP is disabled, so I misunderstood the issue.
Updated•6 months ago
|
Comment 6•5 months ago
|
||
Seeing if we can shim this. Surprisingly this works in Safari.
Comment 7•5 months ago
|
||
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.
Updated•5 months ago
|
Comment 8•5 months ago
|
||
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.
Comment 9•3 months ago
|
||
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.
Description
•