[Fission] Clicking on age-restricted YouTube video embedded on Twitter doesn't work
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox87 | --- | fixed |
People
(Reporter: mccr8, Assigned: nika)
References
Details
Attachments
(3 files)
Steps to reproduce:
- With Fission enabled, go to a Tweet with an age-restricted YouTube video embedded. (I have an example of this but it is obviously not work appropriate content...). The embed shows the name and a thumbnail of the video. (Seems kind of bad that it shows the thumbnail before that, but anyways.)
- Click on the video iframe. This makes the thumbnail and video title go away. Instead, the YouTube iframe is now all black, with text that says "This video is age-restricted and only available on YouTube. Learn more. Watch on YouTube".
- Click on "Watch on YouTube". This pops up a new tab that is completely blank.
Expected behavior: In step 3, the new tab that pops up should load YouTube, with the video. If Fission is disabled it works, but if it is enabled it does not.
According to this page: "Viewers who click on an age-restricted video on another website, such as an embedded player, will be redirected to YouTube/YouTube Music, where they will only be able to view the content when signed-in and over 18."
If you instead click on "Learn More" opens a new YouTube tab as expected. (Presumably it does not need to do the logged-in check.)
The browser console shows this error when I click, which seems related (again, the errors only show up with Fission enabled):
Some cookies are misusing the “SameSite“ attribute, so it won’t work as expected 4
Cookie “_s” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute. _r
Cookie “_s” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”. _r
Cookie “_s” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute. _r
Cookie “_s” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”.
I'll see if I can find or make an age-restricted video that is more work appropriate if necessary. It looks like you can just make any video you upload age-restricted.
The behavior is basically the same if you aren't logged in to YouTube. (The behavior without Fission is that the new YouTube tab opens, but instead of actually showing you the video, it shows you a message stating that you need to be logged in.)
|
Reporter | |
Updated•3 years ago
|
|
|
Reporter | |
Comment 1•3 years ago
|
||
Nika said this sounded more like a navigation issue, despite the cookie errors.
|
|
Reporter | |
Comment 2•3 years ago
|
||
Another weird aspect: if you click on the title of the video in the iframe, then it opens up a new tab with the video just fine.
|
|
Reporter | |
Comment 3•3 years ago
|
||
Another variation: if I use the generic embed HTML that YouTube generates, that looks like the following (with "youtube URL as the actual URL): <iframe width="560" height="315" src="youtube URL" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>... and paste that into an HTML file and load it up locally, then it works just fine. However, with this method of embedding the iframe does NOT contain the title of the video, so I guess it isn't the same script.
|
|
Reporter | |
Comment 4•3 years ago
|
||
Yet another variation. If I paste the YouTube URL into this "card validator" for Twitter, then it does show the title of the video in the iframe, but it works just fine with Fission. https://cards-dev.twitter.com/validator
|
|
Reporter | |
Comment 5•3 years ago
|
||
Ok, I did some extensive searching for examples of age-restricted videos, and I found one that seems to be age restricted because it shows some guy jumping on trains or something. It does reproduce the behavior when I tweeted it: https://twitter.com/amccreight/status/1352000261049315328
|
Assignee | |
Comment 6•3 years ago
|
||
I think this is caused by an interaction between the window opening code and the Cross-Origin-Opener-Policy header, based on a quick investigation and the result from comment 4 that the video works properly with https://cards-dev.twitter.com/validator. The normal https://twitter.com site is served with the header Cross-Origin-Opener-Policy: same-origin, whereas https://cards-dev.twitter.com/validator is not served with that header, which would explain some of the differences.
Interestingly, the "Learn more" link doesn't appear to be impacted at all. The difference there may be due to the "Learn more" link using <a target="_blank"> while the "Watch on YouTube" link uses <a target="TARGET_NEW_WINDOW"> for some reason
Theoretically this may be easy-ish to make a minimal reproduction of. I'll look into getting one put together.
|
|
Assignee | |
Comment 7•3 years ago
|
||
I've figured out the source of the issue here, and am fiddling with tweaking the existing wpt tests to also test anchors and form submissions.
The root cause of the issue is the interaction between the nsDocShell load retargeting logic and the forceNoOpener logic in nsGlobalWindowOuter::OpenInternal which handles documents with Cross-Origin-Opener-Policy. Specifically, the issue occurs when using a <a href="..." target="XXX"> anchor link from a cross-origin iframe within a toplevel document which has set a COOP: same-origin policy, where target is not _blank, meaning that the implicit rel=noopener is not enabled.
Because the link is not considered noopener, the load state does not have the flag INTERNAL_LOAD_FLAGS_NO_OPENER (https://searchfox.org/mozilla-central/rev/8dae1cc76a6b45e05198bc0d5d4edb7bf1003265/docshell/base/nsDocShell.cpp#8520), and so the codepath falls through to the call to OpenNoNavigate to create the new pop-up window. (https://searchfox.org/mozilla-central/rev/8dae1cc76a6b45e05198bc0d5d4edb7bf1003265/docshell/base/nsDocShell.cpp#8582-8585). Unfortunately, the check in nsGlobalWindowOuter::OpenInternal (https://searchfox.org/mozilla-central/rev/8dae1cc76a6b45e05198bc0d5d4edb7bf1003265/dom/base/nsGlobalWindowOuter.cpp#6944-6957) kicks in and detects that we're creating a popup from a cross-origin subframe of a COOP document, and forces the popup creation to be noopener. As the popup was created with OpenNoNavigate, this leads to a random about:blank pop-up being created, and no navigation occurring in it.
The obvious "fix" here would be to detect the forced noopener status before the check in nsDocShell, so that we take the INTERNAL_LOAD_FLAGS_NO_OPENER codepath in this case, but that probably won't work in the general case. Our INTERNAL_LOAD_FLAGS_NO_OPENER codepath is only designed to handle navigations triggered by simple anchor clicks, and can't deal with more complex navigations such as those caused by form submissions, which previously couldn't be made noopener, but now can due to COOP.
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Comment 8•3 years ago
|
||
|
|
Assignee | |
Comment 9•3 years ago
|
||
|
|
Assignee | |
Comment 10•3 years ago
|
||
|
||
Comment 11•3 years ago
|
||
Pushed by nlayzell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f19dfb53d67b Part 1: Test creating popups with anchor clicks and form submissions in coop iframe tests, r=annevk https://hg.mozilla.org/integration/autoland/rev/ea269b827cbe Part 2: Don't use OpenNoNavigate if noopener is force-enabled, r=kmag https://hg.mozilla.org/integration/autoland/rev/436726c3e820 Part 3: Support submitting form data with noopener enabled, r=kmag
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/27403 for changes under testing/web-platform/tests
|
||
Comment 13•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/f19dfb53d67b
https://hg.mozilla.org/mozilla-central/rev/ea269b827cbe
https://hg.mozilla.org/mozilla-central/rev/436726c3e820
Upstream PR merged by jgraham
Description
•