[Affected versions]: Firefox 58.0.2, Firefox 59.0b12, Firefox 60.0a1 [Affected platforms]: Windows 10 x64, macOS 10.12.6, Ubuntu 16.04 x64 [Steps to reproduce]: 1.Launch Firefox 2.Enter www.vimeo.com 3.Start a video 4.Double click on the video to enter fullscreen mode [Expected result]: The video enters fullscreen mode [Actual result]: The video is not entering fullscreen mode This error is thrown in the browser console: Request for fullscreen was denied because Element.requestFullscreen() was not called from inside a short running user-generated event handler. player.js:18:27603 [Regression range]: I tried to find a regression, but the issue is reprodcible on Firefox 34.0a1 (2014-08-20) and on older versions of Firefox videos from Vimeo are not supported. [Additional notes]: Since I haven't found any regression for this issue, I'm not sure that this is related to Bug 687687.

Mike, seen this before?

I don't think we've had this one reported before (not-really-related-ish vimeo fullscreen bug 1396732 comes to mind). This also reproduces at https://player.vimeo.com/api/demo, let me poke around https://github.com/vimeo/player.js. (moving to TE for now)

Tom, can you dig in?

Indeed, using the "f" key on the keyboard works. Double-clicking does not, and yields the console message: > Request for fullscreen was denied because Element.requestFullscreen() was not called from inside a short running user-generated event handler. player.js:19:909 That's in a "request" method in their player.js, which indeed is making the fullscreen request (shown deminified): > try { > !i && t && (m = t.scrollY), e[f.request](), k >= 5.1 && setTimeout(function() { > n[f.element] || x(i ? "not_enabled" : "not_allowed", e) > }, 100) > } catch (t) { > x("not_enabled", e) > } This is the (deminified) stack trace that ends up calling that function: > request https://f.vimeocdn.com/p/2.71.10/js/player.js:19763:1 > v/< https://f.vimeocdn.com/p/2.71.10/js/player.js:9049:232 > de/e.fire https://f.vimeocdn.com/p/2.71.10/js/player.js:580:78 > r/< https://f.vimeocdn.com/p/2.71.10/js/player.js:6595:32 > i https://f.vimeocdn.com/p/2.71.10/js/player.js:11340:28 The initial click event is still being handled in that last line in i, but in the one above it, they fire their own event-to-be-handled within a setTimeout: > s++, 1 === s && setTimeout(function() { > if (o) { > var i = B && B.x === n.clientX && B.y === n.clientY; > return 1 === s && i && !ji.mobileAndroid && e.events.fire(e.telecine.paused ? fc.playButtonPressed : fc.pauseButtonPressed), 1 !== s && e.telecine.getEffectByName("ThreeSixtyEffect").snapToCenter(), void(s = 0) > } > if (1 === s) { > if (t.get(Gv) && !t.get(Xv)) return; > e.events.fire(e.telecine.paused ? fc.playButtonPressed : fc.pauseButtonPressed) > } else e.events.fire(fc.fullscreenButtonPressed); > s = 0 > }, 200) So they are doing something fancy with setTimeout here before they ever try to fullscreen. If I change that entire code-block to simply fire their custom event instead, it works: > e.events.fire(fc.fullscreenButtonPressed); But I'm not at all clear on what the rest of that code is truly trying to accomplish, so I don't know what to recommend here. What do you think, Mike? Is this something we should just relax, or should we reach out to get further information?

I have also encountered this issue when testing the fullscreen launch on twitch.tv using Firefox 61.0b2 devEdition. Firefox 60.0RC is also affected by this issue. The browser console returns the exact same error as for the vimeo video: "Request for fullscreen was denied because Element.requestFullscreen() was not called from inside a short running user-generated event handler." Please note that this does not occur for all the twitch.tv streams. In some cases, the double click launches the fullscreen.

Can you file a new bug for Twitch, Cristian? Unless they're using the same Vimeo player codebase, it's better to address it separately for each site.

(In reply to Thomas Wisniewski from comment #4) > Indeed, using the "f" key on the keyboard works. Double-clicking does not, > and yields the console message: > > > Request for fullscreen was denied because Element.requestFullscreen() was not called from inside a short running user-generated event handler. player.js:19:909 > > That's in a "request" method in their player.js, which indeed is making the > fullscreen request (shown deminified): > > > try { > > !i && t && (m = t.scrollY), e[f.request](), k >= 5.1 && setTimeout(function() { > > n[f.element] || x(i ? "not_enabled" : "not_allowed", e) > > }, 100) > > } catch (t) { > > x("not_enabled", e) > > } > > The initial click event is still being handled in that last line in i, but > in the one above it, they fire their own event-to-be-handled within a > setTimeout: > > > s++, 1 === s && setTimeout(function() { > > if (o) { > > var i = B && B.x === n.clientX && B.y === n.clientY; > > return 1 === s && i && !ji.mobileAndroid && e.events.fire(e.telecine.paused ? fc.playButtonPressed : fc.pauseButtonPressed), 1 !== s && e.telecine.getEffectByName("ThreeSixtyEffect").snapToCenter(), void(s = 0) > > } > > if (1 === s) { > > if (t.get(Gv) && !t.get(Xv)) return; > > e.events.fire(e.telecine.paused ? fc.playButtonPressed : fc.pauseButtonPressed) > > } else e.events.fire(fc.fullscreenButtonPressed); > > s = 0 > > }, 200) > > So they are doing something fancy with setTimeout here before they ever try > to fullscreen. > > If I change that entire code-block to simply fire their custom event > instead, it works: > > > e.events.fire(fc.fullscreenButtonPressed); Xidorn, could you provide a pointer to the code that handles "short running user-generated event handler" for fullscreen? A 100ms timeout seems to make a difference here. Thanks.

(or 200ms?)

It doesn't matter how long is the timeout. We currently always reject fullscreen request for anything async. This seems to be another case related to bug 1185052, where I have a proposal to remove the stack check and allow whatever stuff requiring user input to happen within 1s after the user input happens. That is pending for feedback from security. For the question, the user input check is in nsContentUtils::IsRequestFullScreenAllowed[1], and the code tracking user input is in EventStateManager[2]. [1] https://searchfox.org/mozilla-central/rev/53afcfdbabed96883126d0ebbcac499b358e32f2/dom/base/nsContentUtils.cpp#7191-7196 [2] https://searchfox.org/mozilla-central/rev/53afcfdbabed96883126d0ebbcac499b358e32f2/dom/events/EventStateManager.cpp#4197-4220

(In reply to Mike Taylor [:miketaylr] from comment #6) > Can you file a new bug for Twitch, Cristian? I have done that and the issue is Bug 1459636 . I don't know whether it uses the same player codebase.

Thanks Cristian and Xidorn.

Reproduced on latest Nightly 66.0a1 (2018-12-18) on Mac OS 10.14 on vimeo.com

Reproduced on Nightly 66.0a1 (2018-12-18) on Windows 7 (64-bit)