1249947 - takes 15 seconds for html5 videos to enter fullscreen

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[sam113101]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160211124446

Steps to reproduce:

- play html5 video
- click on the fullscreen button


Actual results:

Takes a long time to completely switch to fullscreen, anywhere from 3 to 15 seconds.


Expected results:

Video should switch to fullscreen mode instantaneously.

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

Xidorn: Can you repro this? Any ideas what's going on?

Comment 2

[Xidorn Quan [:xidorn] UTC+11]

I think I've heard this issue from the reporter several times in #firefox channel... But I have no idea what's happening there. According to the reporter, this issue started existing before I change how fullscreen works, and it happens for both DOM Fullscreen and Fullscreen Mode. So I suppose there could be some issue in the window manager side...

I did see very long time fullscreen change on Linux myself, but that was because the window manager hides the taskbar globally, and waits for the resize flush of some other window, e.g. maximized gvim or terminal, which could be slow. If that's the case, I don't think there is anything doable in our side.

However, IIRC, the reporter denied that this is the case. So I have no idea.

Comment 3

[sam113101]

Attachment: firefox_fullscreen_delay.mp4

At 0:10 I switch to fullscreen, at 0:26 the video starts playing in fullscreen and I start moving my cursor right away, at 0:33 firefox starts responding to the movement of my cursor (the video controls appear). That means it took 23 seconds for firefox to fully switch to fullscreen. Leaving fullscreen is just as painful, as you can see.

The delay grows with time. In a new (freshly started) firefox process, it takes somewhere between 3 and 5 seconds for videos to switch to fullscreen. When firefox has been running for a few hours, I often get delays of more than 15 seconds.

Also happens in a fresh profile, as well as in safe mode.

If you need more information, just ask me.

Comment 4

[Xidorn Quan [:xidorn] UTC+11]

There was a patch in bug 1221659 on Firefox 46 which should significantly improve the transition on Linux, but I failed to get that uplift. I guess that would solve part of your issue.

Could you try setting "full-screen-api.transition-duration.enter" and "full-screen-api.transition-duration.leave" to "0 0" to disable transition, and upload another screencast for the same steps? Changing them doesn't require restarting Firefox, they should take effect immediately.

Comment 5

[sam113101]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #4)
> There was a patch in bug 1221659 on Firefox 46 which should significantly
> improve the transition on Linux, but I failed to get that uplift. I guess
> that would solve part of your issue.
> 
> Could you try setting "full-screen-api.transition-duration.enter" and
> "full-screen-api.transition-duration.leave" to "0 0" to disable transition,
> and upload another screencast for the same steps? Changing them doesn't
> require restarting Firefox, they should take effect immediately.

File was too big to upload here. https://vid.me/czfS

Comment 6

[Xidorn Quan [:xidorn] UTC+11]

From this video, it seems it's the fault of the sidebar extension which takes an extensive time to hide. Could you try using Gecko Profiler [1] to profiling what takes that long time and submit that data [2]?

[1] https://github.com/bgirard/Gecko-Profiler-Addon/
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem#Using_the_profiler

Comment 7

[Xidorn Quan [:xidorn] UTC+11]

Oh, wait... It probably doesn't work. I don't think the symbol server has necessary information for builds from Linux distributions... Could you do that with an official build from mozilla.org?

Comment 8

[sam113101]

https://cleopatra.io/#report=ac2b3abd2e4590033b059cf138d52e71a776c2af

Comment 9

[Xidorn Quan [:xidorn] UTC+11]

I fail to find anything interesting from this report :/

Comment 10

[Wayne Mery (:wsmwk)]

Still see this issue when using a current version?

Comment 11

[Xidorn Quan [:xidorn] UTC+11]

Could you provide a URL which you observe this issue? Is it reliably reproducible?

Comment 12

[Wayne Mery (:wsmwk)]

I do not have a URL. I was mistaken to ask you.

Comment 13

[Wayne Mery (:wsmwk)]

Per comment 6 (and reporter seems to be gone)