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

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

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.

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

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

https://hg.mozilla.org/mozilla-central/rev/b9f3ca50c00e

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!

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.

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.

https://hg.mozilla.org/releases/mozilla-beta/rev/5c154dc2c721

https://hg.mozilla.org/releases/mozilla-beta/rev/5c154dc2c721

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.