1189622 - Full Screen doesn't work in xmonad. Firefox should check _NET_SUPPORTED for fullscreen hint support before relying on its functionality and/or maintain the browser window's fullscreen state separate from the GTK-reported window state.

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[JJ]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150730004009

Steps to reproduce:

1. Open a Firefox window while the xmonad window manager is running
2. Press F11 (or select View -> Full Screen from the menu)


Actual results:

Nothing happens


Expected results:

Firefox should enter Full Screen mode, and hide the toolbars by animating them up (as per the configuration settings browser.fullscreen.autohide and browser.fullscreen.animate).

Comment 1

[Mike Hoye [:mhoye]]

There are a few outstanding xmonad issues for Firefox; I'll move this into Firefox::General.

Comment 2

[Denis Kasak]

I can confirm this is an issue with Firefox 41.0.2.

Comment 3

[h.audren]

This is still an issue in Firefox 42.0 (With Ubuntu 14.04 + xmonad 0.11). 

I opened a thread in reddit (https://www.reddit.com/r/firefox/comments/3rpjfc/fullscreen_issues_in_xmonad/) decribing this issue and another one. Here is the relevant part:

> Pressing the fullscreen button in the hamburger menu and F11 do nothing. However, if I close Firefox and restart it with Fullscreen activated, it starts in fullscreen. In that case, deactivating it does not have any effect on the window until Firefox is restarted.

I have another bug that is probably related (also described in the above link). Fullscreen videos simply do not work. Although firefox picks up the change to fullscreen (because wherever I click in the window, it pauses the video), the video itself is not fullscreen. I cannot seem to exit the fullscreen mode and have to kill the window.

I would be glad to contribute if pointed in the right direction.

Thanks.

Comment 4

[h.audren]

Ok I just checked the source code, and can't find a definition for mozRequestFullScreen() yet but if I understand correctly, this is more of an interface than firefox really implementing it.

However I can confirm that I am also unable to put a pdf in fullscreen, with the same problems as when trying to put a video fullscreen.

Comment 5

[h.audren]

By the way, by digging deeper I found this:
https://code.google.com/p/chromium/issues/detail?id=286545

It appears that xmonad can (and will) decline gtk_window_fullscreen. Thus one should not rely on it completing properly, but this is not checked apparently ? I guess it could be part of the problem.

Comment 6

[Lucian Poston]

(In reply to h.audren from comment #3)
> Fullscreen videos simply do not work. Although firefox picks up the
> change to fullscreen (because wherever I click in the window, it pauses the
> video), the video itself is not fullscreen. I cannot seem to exit the
> fullscreen mode and have to kill the window.

I also have this issue in firefox 42 with xmonad.

In ff 42, when ff enters or exits fullscreen mode, parts of the UI become unresponsive, and it can leave ff stuck in fullscreen mode. My guess is ff gets stuck waiting for _NET_WM_STATE to be updated with _NET_WM_STATE_FULLSCREEN. If the window manager doesn't update _NET_WM_STATE, ff's UI becomes unresponsive.

Firefox doesn't seem to correctly check for EWMH's _NET_WM_STATE_FULLSCREEN support. Firefox should check _NET_SUPPORTED for fullscreen hint support before relying on its functionality. See http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472725888

As a workaround in xmonad, enable EWMH and add fullscreenEventHook to handleEventHook. See http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-EwmhDesktops.html

Comment 7

[drrossum]

I can confirm that in Xmonad, the firefox 42 UI becomes unresponsive when fullscreen mode is entered (F11 is pressed).

Comment 8

[[e-mail]]

I have the same problem when using xmonad. Moreover, trying to play YouTube videos in fullscreen will make the video image seem to freeze while the audio keeps playing. Maybe this should be a separate issue, but it seems related to fullscreen mode in Firefox. Trying to press Alt-j in order to change to "the full screen window" will do nothing or close to nothing; perhaps refresh the window for a fraction of a second. The entire webpage is also non-interactive/frozen, or it does not properly render any more.

There are other issues, like firefox starting in fullscreen mode (transitions with that gliding animation of the address bar) at startup of the program. Then I can't exit this fullscreen mode. I sometimes can't even press F6 in order to get the address bar back, but I might have to look more into that in order to figure out if that is consistently reproducible.

Comment 9

[sacha404]

I'm also suffering the same problem as everyone here, which can indeed be "fixed" by adding fullscreenEventHook to the xmonad config. Unfortunately this is not really desirable for a tiling windows manager, and it would be much better if firefox could respond rationally to have the full screen request denied. No other application I've worked with has failed in this way when having the fullscreen request turned down, and I see no reason why firefox should be any different.

Comment 10

[Adam Plaice]

Firstly, I'd like to report that the problem (of Firefox not going into full-screen and instead slowing down/partially freezing, when you press <F11>), also occurs if you start Firefox in X, without any window manager (e.g. "xinit -- :1" in tty[1-6] and then launch Firefox), so it's not XMonad-specific.

Secondly, to add to the workaround for XMonad, posted above (https://bugzilla.mozilla.org/show_bug.cgi?id=1189622#c6) if what you seek is Firefox going into full-screen within its tile (rather than entering the floating layer) you can slightly modify fullScreenEventHook (copy it from the source and remove the offending lines corresponding to the floating or see https://gist.github.com/aplaice/51137da641abdbe33139 ).

Comment 11

[Xidorn Quan [:xidorn] UTC+11]

I'm not quite familiar with xmonad (or actually, any Linux window manager stuff). It would be great if someone can help.

My first question is, which version of Firefox you are using? Is that still the GTK-based one?

Since some version, Firefox starts to have two phases for switching fullscreen, and the second phase starts after the window is made fullscreen (with some system events).

For our GTK implementation, the start point of the second phase is in nsWindow::OnWindowStateEvent [1], which is called by window_state_event_cb, which is the callback for GTK's window_state_event signal [2]. I'm not quite sure how this signal works, but if it isn't triggered for fullscreen, or doesn't have the correct flags set on xmonad as mentioned in comment 6, then Firefox could misbehave.

I'm not quite sure how this could be fixed. I don't see any singla in GTK which responds to fullscreen change separately.

Could anyone help?


[1] https://dxr.mozilla.org/mozilla-central/rev/e0bcd16e1d4b99ba3e542149d0d41e0f60c54b5c/widget/gtk/nsWindow.cpp#3332-3335
[2] https://dxr.mozilla.org/mozilla-central/rev/e0bcd16e1d4b99ba3e542149d0d41e0f60c54b5c/widget/gtk/nsWindow.cpp#3820-3821

Comment 12

[Xidorn Quan [:xidorn] UTC+11]

If your version doesn't use the GTK widget, then it is possible that the "FullscreenChanged", which can be found in the link above, is not called from that widget.

I only added the new code to our tier-1 widgets, so other widgets may still lack the related code.

Comment 14

[Karl Tomlinson (:karlt)]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #11)
> My first question is, which version of Firefox you are using? Is that still
> the GTK-based one?

This bug is about the GTK port, yes.

> Since some version, Firefox starts to have two phases for switching
> fullscreen, and the second phase starts after the window is made fullscreen
> (with some system events).
> 
> For our GTK implementation, the start point of the second phase is in
> nsWindow::OnWindowStateEvent [1], which is called by window_state_event_cb,
> which is the callback for GTK's window_state_event signal [2]. I'm not quite
> sure how this signal works, but if it isn't triggered for fullscreen, or
> doesn't have the correct flags set on xmonad as mentioned in comment 6, then
> Firefox could misbehave.

Yes, I expect this is the issue reported here and in bug 1214768.
On some window managers, the fullscreen state is not supported.

I assume the fullscreen requests from gtk_window_fullscreen() and gtk_window_unfullscreen() are simply ignored and so there is no response received in OnWindowStateEvent().  I'm assuming that previously all that F11 would do is change the appearance of the Gecko window, without actually changing the size.

> I'm not quite sure how this could be fixed. I don't see any singla in GTK
> which responds to fullscreen change separately.

The code is listening for the right signal, but no signal is generated.

These window managers that don't send this signal can be detected by using
gdk_x11_screen_supports_net_wm_hint with the _NET_WM_STATE_FULLSCREEN atom.

Perhaps MakeFullScreen() could return NOT_SUPPORTED in those situations, so that callers don't wait for the response, or perhaps it could simulate the events of a fullscreen transition.

Comment 15

[Xidorn Quan [:xidorn] UTC+11]

(In reply to Karl Tomlinson (ni?:karlt) from comment #14)
> I assume the fullscreen requests from gtk_window_fullscreen() and
> gtk_window_unfullscreen() are simply ignored and so there is no response
> received in OnWindowStateEvent().  I'm assuming that previously all that F11
> would do is change the appearance of the Gecko window, without actually
> changing the size.

If that's the case, I have a workaround for users of those window manager. You could set "full-screen-api.ignore-widgets" to true, so that Firefox would not bother the window size, just change the appearance.

> These window managers that don't send this signal can be detected by using
> gdk_x11_screen_supports_net_wm_hint with the _NET_WM_STATE_FULLSCREEN atom.
> 
> Perhaps MakeFullScreen() could return NOT_SUPPORTED in those situations, so
> that callers don't wait for the response, or perhaps it could simulate the
> events of a fullscreen transition.

Thanks for this information.

I'm going to add a function to widget to check whether the system actually supports fullscreen, and if not, do what exactly "full-screen-api.ignore-widgets" does (change the appearance but not change the window size). Do you think this is the right way to go?

Comment 16

[drrossum]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #15)

> You could set "full-screen-api.ignore-widgets" to true, so that Firefox
> would not bother the window size, just change the appearance.

I can confirm that setting this preference solves the problem with using F11 in XMonad.  Thank you for providing this solution!

Comment 17

[Karl Tomlinson (:karlt)]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #15)
> (In reply to Karl Tomlinson (ni?:karlt) from comment #14)
> > Perhaps MakeFullScreen() could return NOT_SUPPORTED in those situations, so
> > that callers don't wait for the response, or [...]

> I'm going to add a function to widget to check whether the system actually
> supports fullscreen, and if not, do what exactly
> "full-screen-api.ignore-widgets" does (change the appearance but not change
> the window size). Do you think this is the right way to go?

If you need to know whether MakeFullScreen() will succeed before actually calling it, then this is appropriate.

I'm don't know whether or not the lack of MakeFullScreen() support should mean that the transition is skipped.  If the transition is independent from widget sizing, then an error return value from MakeFullScreen() is probably sufficient.

Comment 18

[Xidorn Quan [:xidorn] UTC+11]

Oh, okay, that sounds reasonable.

Comment 19

[Xidorn Quan [:xidorn] UTC+11]

Hmmm, making MakeFullScreen fallible seems to actually need more change due to the current code for setting fullscreen change flag. Also if the window doesn't really cover the whole screen, a fullscreen transition could seem weird. I'll go the comment 14 way.

Comment 20

[Xidorn Quan [:xidorn] UTC+11]

Attachment: MozReview Request: Bug 1189622 part 1 - Ensure the in-fullscreen-change flag is set before calling the second phase.

Review commit: https://reviewboard.mozilla.org/r/30289/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/30289/

Comment 21

[Xidorn Quan [:xidorn] UTC+11]

Attachment: MozReview Request: Bug 1189622 part 2 - Allow widget's MakeFullScreen to fail, and call FinishFullscreenChange directly if that happens.

Review commit: https://reviewboard.mozilla.org/r/30291/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/30291/

Comment 22

[Xidorn Quan [:xidorn] UTC+11]

Attachment: MozReview Request: Bug 1189622 part 3 - Return failure for if fullscreen support is not available for the X11 desktop.

Review commit: https://reviewboard.mozilla.org/r/30293/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/30293/

Comment 23

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8706231 [details]
MozReview Request: Bug 1189622 part 1 - Ensure the in-fullscreen-change flag is set before calling the second phase.

https://reviewboard.mozilla.org/r/30289/#review27073

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8706232 [details]
MozReview Request: Bug 1189622 part 2 - Allow widget's MakeFullScreen to fail, and call FinishFullscreenChange directly if that happens.

https://reviewboard.mozilla.org/r/30291/#review27077

Comment 25

[Karl Tomlinson (:karlt)]

Comment on attachment 8706233 [details]
MozReview Request: Bug 1189622 part 3 - Return failure for if fullscreen support is not available for the X11 desktop.

https://reviewboard.mozilla.org/r/30293/#review27195

Comment 26

[Xidorn Quan [:xidorn] UTC+11]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f521bf0274c7c7a5d6bc6c24428e0b15166ca7eb
Bug 1189622 part 1 - Ensure the in-fullscreen-change flag is set before calling the second phase. r=smaug

https://hg.mozilla.org/integration/mozilla-inbound/rev/e6c5bc713b540136c4a7da91b37daa5dc7b8b36b
Bug 1189622 part 2 - Allow widget's MakeFullScreen to fail, and call FinishFullscreenChange directly if that happens. r=smaug

https://hg.mozilla.org/integration/mozilla-inbound/rev/8e52730bd8ee9d9037f9e278b0e30631c4f85e5b
Bug 1189622 part 3 - Return failure if fullscreen support is not available for the X11 desktop. r=karlt

Comment 27

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f521bf0274c7
https://hg.mozilla.org/mozilla-central/rev/e6c5bc713b54
https://hg.mozilla.org/mozilla-central/rev/8e52730bd8ee

Comment 29

[Mike Limansky]

Is there any chance to have this fix in ESR version as well?

Comment 30

[Xidorn Quan [:xidorn] UTC+11]

I don't think so, because the patch isn't very trivial. You can always workaround this issue via setting "full-screen-api.ignore-widgets" to true in about:config. (You may need to create a new bool value with that name)

Comment 31

[Mike Limansky]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #30)
> I don't think so, because the patch isn't very trivial. You can always
> workaround this issue via setting "full-screen-api.ignore-widgets" to true
> in about:config. (You may need to create a new bool value with that name)

1. Well, I've already applied the patch on top of the FF 45.2.0 on my Gentoo laptop and it fixed the issue.  I can attach the patch (but it's the same except the line numbers) if it required.

2. There is no "full-screen-api.ignore-widgets". I don't know why..

Comment 32

[Xidorn Quan [:xidorn] UTC+11]

(In reply to Mike Limansky from comment #31)
> (In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #30)
> > I don't think so, because the patch isn't very trivial. You can always
> > workaround this issue via setting "full-screen-api.ignore-widgets" to true
> > in about:config. (You may need to create a new bool value with that name)
> 
> 1. Well, I've already applied the patch on top of the FF 45.2.0 on my Gentoo
> laptop and it fixed the issue.  I can attach the patch (but it's the same
> except the line numbers) if it required.

That may work, yes, but I don't think release managers want to take the risk of breaking anything, and I don't think it's worth asking them...

> 2. There is no "full-screen-api.ignore-widgets". I don't know why..

Right, you need to create a new bool pref. It doesn't appear by default.