1441881 - Entering fullscreen with double click on vimeo videos does not work

Status: RESOLVED DUPLICATE of bug 1129227

(Web Compatibility :: Site Reports, defect, P1)

Description

[Catalin Sasca, Desktop Test Engineering [:csasca]]

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

Comment 1

[Anne (:annevk)]

Mike, seen this before?

Comment 2

[Mike Taylor [:miketaylr]]

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)

Comment 3

[Mike Taylor [:miketaylr]]

Tom, can you dig in?

Comment 4

[Thomas Wisniewski]

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?

Comment 5

[Cristian Baica [:cbaica], Release Desktop QA]

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.

Comment 6

[Mike Taylor [:miketaylr]]

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.

Comment 7

[Mike Taylor [:miketaylr]]

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

Comment 8

[Mike Taylor [:miketaylr]]

(or 200ms?)

Comment 9

[Xidorn Quan [:xidorn] UTC+10]

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

Comment 10

[Cristian Baica [:cbaica], Release Desktop QA]

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

Comment 11

[Mike Taylor [:miketaylr]]

Thanks Cristian and Xidorn.

Comment 12

[Timea Cernea [:tbabos][inactive]]

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

Comment 13

[Peter Magyari (Desktop QA)]

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

Comment 14

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 15

[Marcela (Please NI request to Brindusa Tot)]

Reproducible in Windows10
Version 68.0a1
Build ID 20190513215004
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Comment 16

[Edgar Chen [:edgar] (Parental leave until Oct. 09.)]

bug 1129227 should fix this and I could not reproduce on recent nightly (20191101093621).