Closed Bug 1545807 Opened 1 year ago Closed 1 year ago

Cannot read video from Twitter on afp website (french press agency).

Categories

(Core :: DOM: Core & HTML, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla68
Tracking Status
firefox-esr60 --- unaffected
firefox66 --- unaffected
firefox67 + verified
firefox68 --- verified

People

(Reporter: calixte, Assigned: ehsan)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

STR:

  1. open firefox with a fresh profile
  2. log in your twitter account
  3. open a new tab with url: https://factuel.afp.com/un-point-lumineux-sur-les-echafaudages-de-notre-dame-avant-lincendie-une-vraie-video-mais-qui-ne
  4. Click on the first video ("No workers onsite. Who tf is this?")
  5. The video doesn't play

In using mozregression, I get:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=74b2c66643c90b1a7f161136bdf0ce8fa1178396&tochange=87b426177fadd80991f6234939daeb80f9b17130

Has Regression Range: --- → yes
Has STR: --- → yes

[Tracking Requested - why for this release]:
Recent regression in beta

I started to have a look at this today. Don't know what's going on yet...

Flags: needinfo?(ehsan)

The following video also doesn't seem to work properly. It starts to play but stops at around 6 seconds in and doesn't continue. Tested in Beta 67.0b12 (64-bit) and today's Nightly (with a fresh profile). It plays fine in Chrome.

https://twitter.com/LukasStefanko/status/1120649962579275777

The failure is coming from this early return: https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/dom/base/ThirdPartyUtil.cpp#191. We have a situation here where we have the following window hierarchy:

  * https://factuel.afp.com
    * about:blank (inheriting principal)
      * https://www.youtube.com

Here the parent points to the about:blank iframe. parentDomain is empty there since Document::SetDocumentURI() is never called for the middle iframe.

Flags: needinfo?(ehsan)

(In reply to jiri.pospisil from comment #3)

The following video also doesn't seem to work properly. It starts to play but stops at around 6 seconds in and doesn't continue. Tested in Beta 67.0b12 (64-bit) and today's Nightly (with a fresh profile). It plays fine in Chrome.

https://twitter.com/LukasStefanko/status/1120649962579275777

I can't reproduce this... But anyway this is a completely different issue, so please file a separate bug for it. Thanks!

Going back to the original topic of the bug, I have a fix for this, but unfortunately I'm not sure how to write a test for it... In my debugging session I couldn't completely figure out what it was that was ultimately breaking the playback as a result of us taking that early return branch so I'm just gonna attach my fix here.

Assignee: nobody → ehsan
Priority: -- → P2
Pushed by eakhgari@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b9f3ca50c00e
Fall back to the principal-based slow code path inside ThirdPartyUtil::IsThirdPartyWindow() when we face a document without a cached base domain; r=baku

Comment on attachment 9060174 [details]
Bug 1545807 - Fall back to the principal-based slow code path inside ThirdPartyUtil::IsThirdPartyWindow() when we face a document without a cached base domain;

Beta/Release Uplift Approval Request

  • User impact if declined: Comment 0
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Comment 0
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This basically restores the old slow code path in cases where the optimization added in bug 1525356 fails to work, so it takes us back to the same old behaviour we had before that bug.
  • String changes made/needed: None
Attachment #9060174 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Regressions: 1547191

Comment on attachment 9060174 [details]
Bug 1545807 - Fall back to the principal-based slow code path inside ThirdPartyUtil::IsThirdPartyWindow() when we face a document without a cached base domain;

Not taking for beta as this seems to have caused crash bug 1547191 with a rather high volume on nightly. If it turns out that this patch was not the regressor, please feel free to request uplift again, thanks!

Attachment #9060174 - Flags: approval-mozilla-beta? → approval-mozilla-beta-

Good call. I'm looking into the crash right now...

Comment on attachment 9060174 [details]
Bug 1545807 - Fall back to the principal-based slow code path inside ThirdPartyUtil::IsThirdPartyWindow() when we face a document without a cached base domain;

See comment 9. Also needs bug 1547191.

Attachment #9060174 - Flags: approval-mozilla-beta- → approval-mozilla-beta?

Comment on attachment 9060174 [details]
Bug 1545807 - Fall back to the principal-based slow code path inside ThirdPartyUtil::IsThirdPartyWindow() when we face a document without a cached base domain;

Approved for 67 beta 15 as it affects top sites and the crash the patch generated is now fixed as well, thanks.

Attachment #9060174 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

I have reproduced this issue using Firefox 68.0a1 (2019.04.19) on Win 10 x64.
I can confirm this issue is fixed, I verified using Firefox 67.0b15 and latest nightly 68.0a1, on Win 10 x64, macOS 10.13.6 and Ubuntu 18.04 x64.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.