Closed Bug 1441881 Opened 4 years ago Closed 2 years ago

Entering fullscreen with double click on vimeo videos does not work

Categories

(Web Compatibility :: Desktop, defect, P1)

defect

Tracking

(firefox60 wontfix, firefox64 wontfix, firefox65 fix-optional, firefox66 fix-optional, firefox67 affected, firefox68 affected, firefox69 affected)

RESOLVED DUPLICATE of bug 1129227
Tracking Status
firefox60 --- wontfix
firefox64 --- wontfix
firefox65 --- fix-optional
firefox66 --- fix-optional
firefox67 --- affected
firefox68 --- affected
firefox69 --- affected

People

(Reporter: csasca, Assigned: edgar)

References

Details

(Keywords: webcompat:needs-diagnosis, Whiteboard: [needsdiagnosis][platform-rel-Vimeo])

[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?
Flags: needinfo?(miket)
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)
Component: DOM: Core & HTML → Desktop
Flags: needinfo?(miket)
Product: Core → Tech Evangelism
Whiteboard: [needsdiagnosis][platform-rel-Vimeo]
Tom, can you dig in?
Flags: needinfo?(twisniewski)
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?
Flags: needinfo?(twisniewski) → needinfo?(miket)
Priority: -- → P1
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.
Flags: needinfo?(cristian.baica)
(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.
Flags: needinfo?(miket) → needinfo?(xidorn+moz)
(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
Flags: needinfo?(xidorn+moz)
See Also: → 1185052
(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.
Flags: needinfo?(cristian.baica)
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)
Product: Tech Evangelism → Web Compatibility

See bug 1547409. Moving webcompat whiteboard tags to keywords.

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

Depends on: 1129227
See Also: 1185052

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

Assignee: nobody → echen
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1129227
You need to log in before you can comment on or make changes to this bug.