GNOME Bugzilla – Bug 721459
Maximize without title bar causes fullscreen
Last modified: 2021-07-05 14:25:12 UTC
After editing "metacity-theme-3.xml" in such way: <frame_geometry name="max" title_scale="medium" parent="normal" rounded_top_left="false" rounded_top_right="false" has_title="false"> <distance name="title_vertical_pad" value="0"/> <border name="title_border" left="0" right="0" top="0" bottom="0"/> <border name="button_border" left="0" right="0" top="0" bottom="0"/> <distance name="bottom_height" value="0" /> That is to remove title bar. But maximized programs start thinking they are in fullscreen mode. For example, Firefox, PhpStorm (Java program, but anyway). And it stucks in fullscreen, and it is difficult to unfullscreen and unmaximize it.
Yes, this is the expected behavior, to handle applications that cannot fullscreen properly (with _NET_WM_FULLSCREEN) and instead just map a screen size window - which is what happens if you remove decorations and have no struts.
We should probably remove that old hack.
(In reply to comment #1) > Yes, this is the expected behavior, to handle applications that cannot > fullscreen properly (with _NET_WM_FULLSCREEN) and instead just map a screen > size window - which is what happens if you remove decorations and have no > struts. Is it possible to change such behavior with some parameter i dconf or something like this? Currently I fixed this by remaining 1px border. <border name="title_border" left="0" right="0" top="0" bottom="1"/>
(In reply to comment #2) > We should probably remove that old hack. That creates more problems that it solves (breaks applications, this works with pretty much every window manager the same way) ... so why?
(In reply to comment #4) > That creates more problems that it solves (breaks applications, this works with > pretty much every window manager the same way) ... so why? Maximizing a CSD window on a non-primary monitor (monitor without struts) validly creates a ConfigureRequest for the full-screen. Maybe what we could do is not apply the workaround if the window has _NET_WM_STATE_FULLSCREEN.
I have such behavior on primary and secondary monitor. Although top panel on primary monitor is present. This looks like crutch, this is not a solution. > so why? Because problem should be solved, workarounds may be temporary, not permanent.
(In reply to comment #5) > Maximizing a CSD window on a non-primary monitor (monitor without struts) > validly creates a ConfigureRequest for the full-screen. Maybe what we could do > is not apply the workaround if the window has _NET_WM_STATE_FULLSCREEN. erm, I meant if the window has _NET_WM_STATE_MAXIMIZED.
(In reply to comment #7) > (In reply to comment #5) > > Maximizing a CSD window on a non-primary monitor (monitor without struts) > > validly creates a ConfigureRequest for the full-screen. Maybe what we could do > > is not apply the workaround if the window has _NET_WM_STATE_FULLSCREEN. > > erm, I meant if the window has _NET_WM_STATE_MAXIMIZED. Yeah that would make more sense then just removing it. But not sure if this hits some corner cases or not Owen should know.
(In reply to comment #5) > Maximizing a CSD window on a non-primary monitor (monitor without struts) > validly creates a ConfigureRequest for the full-screen. Maybe what we could do > is not apply the workaround if the window has _NET_WM_STATE_FULLSCREEN. That's already the case, see bug 708718.
Yeah, the issue here is the fairly arbitrary edge case of having "invisible" server-side decorations. The app is fine otherwise, so we should just ignore it if it's _NET_WM_STATE_MAXIMIZED.
Created attachment 271459 [details] [review] constraints: Don't full-screen maximized applications If an application is validly maximized, it shouldn't ever be legacy-fullscreened. This is the case for client-decorated windows, windows which have hide-titlebar-when-maximized set, and users who force the titlebar off by modifying their metacity theme.
Review of attachment 271459 [details] [review]: Do we know that this does not break existing applications? This behavior has been there for a long time.
I'd say that any application that knows how to maximize itself with _NET_WM_STATE should also know better than to fullscreen with a ConfigureRequest.
(In reply to comment #13) > I'd say that any application that knows how to maximize itself with > _NET_WM_STATE should also know better than to fullscreen with a > ConfigureRequest. Sure that how things *should* be but I am not sure this is actually the case. Owen might know for sure.
So imagine that you have an app that remembers the size it had last time it was run, but not the maximization state. This is very plausible. Such an app will create a maximized window the size of the screen on startup and look very much like the app that is trying to create a legacy fullscreen window. We can't distinguish the two based on maximization. (I think we actually auto-maximize both of these windows right now - but even if we don't because the legacy fullscreen check runs first - we'll still get one or the other wrong.) The thing that seems like it probably should work is to exclude decorated windows from legacy fullscreen. The history here is that in bug 708718 we did: if (meta_prefs_get_force_fullscreen() && !window->hide_titlebar_when_maximized && + window->decorated && meta_rectangle_equal (new, &monitor_info->rect) && window->has_fullscreen_func && !window->fullscreen) And in bug 723029 (not yet landed) I did: if (meta_prefs_get_force_fullscreen() && !window->hide_titlebar_when_maximized && - window->decorated && + (window->decorated || !window->has_custom_frame_extents) && meta_rectangle_equal (new, &monitor_info->rect) && window->has_fullscreen_func && !window->fullscreen) But maybe we really want: if (meta_prefs_get_force_fullscreen() && !window->hide_titlebar_when_maximized && - (window->decorated || !window->has_custom_frame_extents) && + !window->decorated && + !window->has_custom_frame_extents && meta_rectangle_equal (new, &monitor_info->rect) && window->has_fullscreen_func && !window->fullscreen) My reasoning here is that the idea of legacy fullscreen is that it is supposed to work if the window manager doesn't understand fullscreen - and making a screensize window doesn't simulate "fullscreen" very well unless you turn off decoration However, I don't think we should land this right before 3.12 if the only thing that we're fixing is custom themes. Especially since we don't have a good sense of what apps are relying on legacy fullscreen so don't have any way to make sure we've done sufficient testing.
Review of attachment 271459 [details] [review]: Marking needs-work based on Owen's comment.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.