Open Bug 1642832 Opened 1 month ago Updated 1 month ago

Embedded Twitter videos broken in Beta and Release

Categories

(Web Compatibility :: Desktop, defect, P1)

Tracking

(firefox-esr68 unaffected, firefox76 unaffected, firefox77 affected, firefox78 affected)

REOPENED
Tracking Status
firefox-esr68 --- unaffected
firefox76 --- unaffected
firefox77 --- affected
firefox78 --- affected

People

(Reporter: englehardt, Unassigned)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: regressionwindow-wanted)

Attachments

(3 files)

This issue is distinct from the breakage we've observed caused by ETP (see Bug 1641521) and reproduces with ETP disabled. I can reproduce the issue in Firefox release (v77 build 20200528194502) and beta (v78.0b1 build 20200601142750) but not the latest Nightly.

STR:

ER: the video plays

AR: the embedded widget displays "The media could not be played." (see attached screenshot)

After clearing cookies from twitter.com, the video on the verge will play again. Revisiting twitter.com directly will cause the same failure on future refreshes of The Verge. I've also verified that this reproduces on other first parties (e.g., the NYT).

I can't reproduce.
This is working for me on 78.0a1 (2020-06-01) (64-bit)
macOS 10.15.5 (19F101)
macbookpro

which is consistent with

I can reproduce the issue in Firefox release (v77 build 20200528194502) and beta (v78.0b1 build 20200601142750) but not the latest Nightly.

Probably a mozregression find-fix could reveal what is happening. It doesn't seem to be a webcompat issue though.

Fixed range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=234ea58aa683940894eee00ece8ef0626640fb74&tochange=9bb7f1d7f4e8aa5f9f3e3c6897ffc91242a846ec

And Set network.cookie.sameSite.laxByDefault to true will fix for Beta78.0b1.
(FYI, network.cookie.sameSite.laxByDefault is true on Nightly Build only.)

Bug 1627653 has been partially reverted by bug 1641459, landed in 78.

Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1627653

I can actually reproduce this issue using a yesterday build. I'm debugging this issue.

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Severity: -- → S1
Priority: -- → P1

I've been comparing profiles that work vs. don't work (on release).

Difference seems to be a 403 on the request to their API server:

https://api.twitter.com/1.1/videos/tweet/config/1268658364944441346.json

This message shows in the console:

Request URL:https://api.twitter.com/1.1/videos/tweet/config/1268658364944441346.json
This URL matches a known tracker and it would be blocked with Content Blocking enabled.

So at seems like on release at least, this would be tracker related. But the weird thing is that on both these profiles, I have the same level of tracking protection enabled (Standard).

And it's also odd that the error doesn't happen until you actually click on the video. If it was tracker related, you'd think the embed would fail completely.

Comparing the two requests, the header information is very different.

Maybe it's unrelated, but it could be a dup of bug 1642832.

:mkaply can you provide HAR recordings of your repro (possibly privately to asuth@mozilla.com) and/or indicate what the contents of the 403 response were (the body not the headers)? One possibility is something like the bug 1589764 situation where twitter's CSRF defenses are getting desynchronized.

Flags: needinfo?(mozilla)
See Also: → 1589764

(In reply to Andrea Marchesini [:baku] from comment #8)

Maybe it's unrelated, but it could be a dup of bug 1642832.

I meant bug 1637325

Response data is:

{"errors":[{"code":239,"message":"Bad guest token."}]}

I can reproduce this at will on a particular profile, so let me know if you want to take a look.

Flags: needinfo?(mozilla)
You need to log in before you can comment on or make changes to this bug.