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.

RESOLVED FIXED in Firefox 46

Status

()

Core
Widget: Gtk
RESOLVED FIXED
2 years ago
11 months ago

People

(Reporter: JJ, Assigned: xidorn)

Tracking

41 Branch
mozilla46
All
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox46 fixed)

Details

User Story

(In reply to Lucian Poston from comment #6)

> (In reply to h.audren from comment #3)
> 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


Workaround 2: Go to about:config. Set "full-screen-api.ignore-widgets" to true, so that Firefox would not bother changing the window size, but just change the appearance.

https://code.google.com/p/chromium/issues/detail?id=286545

2. Fixed existing bug where browser fullscreen mode (e.g., for HTML5 video) was completely broken for any window manager that does not respect GTK's fullscreen API (e.g., XMonad).  The solution here is to maintain the browser window's fullscreen state separate from the GTK-reported window state.

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(3 attachments)

(Reporter)

Description

2 years ago
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

2 years ago
There are a few outstanding xmonad issues for Firefox; I'll move this into Firefox::General.
Component: Untriaged → General

Comment 2

2 years ago
I can confirm this is an issue with Firefox 41.0.2.

Comment 3

2 years ago
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

2 years ago
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

2 years ago
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

2 years ago
(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

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

Comment 8

2 years ago
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

2 years ago
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.

Updated

a year ago
Blocks: 1214768

Updated

a year ago
Status: UNCONFIRMED → NEW
Has STR: --- → yes
User Story: (updated)
Component: General → Widget: Gtk
Ever confirmed: true
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → All
Summary: Full Screen doesn't work in xmonad → 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.

Comment 10

a year ago
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 ).
(Assignee)

Updated

a year ago
Flags: needinfo?(quanxunzhen)
(Assignee)

Comment 11

a year ago
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
Flags: needinfo?(quanxunzhen)
(Assignee)

Comment 12

a year ago
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.
No longer blocks: 1214768
Duplicate of this bug: 1214768
(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.
(Assignee)

Comment 15

a year ago
(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?
Flags: needinfo?(karlt)

Comment 16

a year ago
(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!

Updated

a year ago
User Story: (updated)
(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.
Flags: needinfo?(karlt)
(Assignee)

Comment 18

a year ago
Oh, okay, that sounds reasonable.
(Assignee)

Comment 19

a year ago
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.
(Assignee)

Comment 20

a year ago
Created attachment 8706231 [details]
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/
Attachment #8706231 - Flags: review?(bugs)
(Assignee)

Comment 21

a year ago
Created attachment 8706232 [details]
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/
Attachment #8706232 - Flags: review?(bugs)
(Assignee)

Comment 22

a year ago
Created attachment 8706233 [details]
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/
Attachment #8706233 - Flags: review?(karlt)
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
Attachment #8706231 - Flags: review?(bugs) → review+
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
Attachment #8706232 - Flags: review?(bugs) → review+
Attachment #8706233 - Flags: review?(karlt) → review+
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
(Assignee)

Comment 26

a year ago
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
(Assignee)

Updated

a year ago
Assignee: nobody → quanxunzhen

Comment 27

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/f521bf0274c7
https://hg.mozilla.org/mozilla-central/rev/e6c5bc713b54
https://hg.mozilla.org/mozilla-central/rev/8e52730bd8ee
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox46: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
(Assignee)

Updated

a year ago
Duplicate of this bug: 1251267
Depends on: 1273746

Updated

a year ago
Blocks: 1279634
(Assignee)

Updated

a year ago
No longer blocks: 1279634
Depends on: 1279634

Comment 29

11 months ago
Is there any chance to have this fix in ESR version as well?
(Assignee)

Comment 30

11 months ago
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

11 months ago
(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..
(Assignee)

Comment 32

11 months ago
(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.
You need to log in before you can comment on or make changes to this bug.