[Affected versions]:

• 68.0esr
• 69.0a1 (2019-07-05)
• 68.0 - build 2

[Affected platforms]:

• Ubuntu 18.04 x64
• Windows 10 x64
• macOS 10.13

[Steps to reproduce]:

1. Go to https://www.aol.com/video/
2. Click on the fullscreen button

[Expected result]:

• Video enters in fullscreen

[Actual result]:

• Nothing happens

[Regression range]:

• Reproducible also on older build (60.7.0esr). I will provide more information asap.

[Additional Notes]:

• Not reproducible on Chrome
• The following error is triggered inside browser console:
  RemoteWebProgress failed to call onStatusChange: [Exception... "JavaScript component does not have a method named: "onStatusChange"'JavaScript component does not have a method named: "onStatusChange"' when calling method: [nsIWebProgressListener::onStatusChange]" nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)" location: "JS frame :: resource://gre/modules/RemoteWebProgress.jsm :: _callProgressListeners :: line 103" data: no]

This issue is not a regression, I've managed to reproduced way back to Fx 31.0a1; on even older builds Fullscreen button is not visible.

The console records the reason that we reject fullscreen request:

Request for fullscreen was denied because at least one of the document’s containing elements is not an iframe or does not have an “allowfullscreen” attribute.

And indeed the video is from an <iframe> without allowfullscreen:

<iframe width="100%" height="100%" frameborder="0"></iframe>

I checked the Fullscreen spec, and found that there is something new since we implemented the strategy, specifically the Feature Policy Integration, which indicates that when allowfullscreen is not set, "its default allowlist is 'self'". And based on the Feature Policy document, 'self' means same-origin child document is allowed, which seems to be the case here.

So my assumption is that we need to implement the feature policy integration for Fullscreen API in order to have this work.

Since Feature Policy seems to belong to DOM: Security component, I'm moving it there.

Removing the regressionwindow-wanted keyword based on comment 1

Reproduced on latest beta build 70.0b5 and Nightly build 71.0a1 (2019-09-12) on Windows 7 x64.

Reproduced on latest Nightly build 72.0a1 (2019-11-06) using Windows 8.

Reproduced on latest Nightly build 73.0a1 (2019-12-10).
The issue is also reproducible on https://huffingtonpost.com.

This issue was reproducible on Windows 10 with Firefox Nightly version 74.0a1 (2020-01-14) (64-bit). Marked as affected.

In light of the finding in bug 1613115, a check on other AOL owned websites revealed the issue present on others as well; as for the initial report:

• https://huffingtonpost.com/videos/
• https://www.engadget.com/videos/
• https://techcrunch.com/video/

Hi,

I'm able to reproduce this issue on Windows for Firefox Nigthly 75.0a1 (2020-02-20). Marking that flag as affected.

Hi,

I'm able to reproduce this issue on Windows for Firefox Nigthly 76.0a1 (2020-03-16). Marking that flag as affected.

I was abale to reproduce this issue on lates Nightly version76.0a1 (2020-03-17) on Ubuntu 18.04.

Is this really regressed by bug 1617219? I would think it's more like "depends on", right? I'm not sure why it still doesn't work though, "self" should be the default allowlist value by now.

I would expect this to affect other sites as well if it works in Chrome, so we should probably take a look at this sooner rather than later.