After top or bottom snapping, maximized window is difficult to access

Bug #1397922 reported by Yvan Masson on 2014-12-01
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
xfwm4 (Debian)
xfwm4 (Ubuntu)

Bug Description

Dear maintainers,

On Xubuntu 14.04 (and also Debian Jessie), maximizing a window (double click on the title bar or clicking to the "+" button) after using snapping (dragging to a screen edge) is problematic : the window will sometimes be placed in a way that you can not move it anymore easily.

The worst example:
My panel is on the bottom. If I drag a window to the bottom of the screen, the window "snaps" and then takes the half bottom of the screen. But then, if I try to maximize this window, the window disappears : only a part of the title bar is visble, hidden behind the panel. The only way I found to make it visible again is to right click on the window's name on the task panel and to choose "Maximize". After that, if I unmaximize the window, it disappears again, so I must drag the maximised window to the middle of the screen f I do not want it maximized anymore.

A "less worst example":
My panel is on top. If I drag a window to the top of the screen, the window "snaps" and then takes the half top of the screen. The title bar of the window is almost completely hidden under the panel (using Xubuntu 14.04 default appearance). You can move it, but it is difficult (or you have to know how to use the Alt key).

In my opinion, in this context the window should return to the middle of the screen, or at least not be allowed to go outside of it.

Thanks for your time and work,

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: xfwm4 4.11.1-2ubuntu2
ProcVersionSignature: Ubuntu 3.13.0-40.69-generic
Uname: Linux 3.13.0-40-generic i686
ApportVersion: 2.14.1-0ubuntu3.5
Architecture: i386
CurrentDesktop: XFCE
Date: Mon Dec 1 10:41:40 2014
InstallationDate: Installed on 2014-11-24 (7 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release i386 (20140416.2)
SourcePackage: xfwm4
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

When tiling a maximised window, you would expect later clicking on the maximise button on the title bar to maximise the window again. This is not the case. It actually performs an unmaximise action.

To re-produce, open a window and maximise it. Drag to left or right to tile the window. Now click the maximise button and the window unmaximises.

It would seem when a maximised window is tiled, the WNCK_WINDOW_IS_MAXIMIZED flag is not unset, leading xfwm4 to believe it is still maximised and perform an ummaximise next time the button is clicked.


This does not happen with all windows.

Using xfce4-terminal and thunar, these apps display the correct behaviour. Using mousepad or firefox display the incorrect behaviour.

xfwm4 does not use nor depend on libwnck.

Tiling in xfwm4 works in conjuction with (partial) maximization, either vertically or horizontally.

Better check the EWMH flags for maximization, if those do not match the actual state, then there could be a bug.

Download full text (3.3 KiB)

Apologies for the delay in responding.

After some more intense investigation on my end, it would appear to not be a bug as such, more intended behaviour but un-expected behaviour (from the user standpoint) from tiling, as follows:

Using the following bitmask for window states:

I get the following behaviour from all windows (my mistake in thinking thunar behaved differently to firefox etc, turns out to just be intended, but un-expected behaviour of xfwm4)

1. Start window normal: 0 (bit mask)
2. Maximize window: 6
3. Move the window: 0 window resizes to state before maximize
4. Maximzise window: 6
5. Move window to left or right to tile: 0 only an unmaximize is triggered, when window reaches left or right egde, a vertical maximize is not triggered (unsure if this is intended or cannot be avoided but I would expect the state to change to 4 and the window be tiled to the left or right)
6. Release window and then move to left or right to tile: 4
7. Move window: 0
8. Move window to left or right to tile: 4
9. Maximize window button: 0 the window reverts to normal state and the position is at the last remembered co-ordinates before the vertical maximize in step 8 was triggered. I would expect the window to maximize here (bitmask 6) as even though the window is maximized in one direction, the logical state would be normal (bit mask 0), but users would not consider a vertical (or horizontal) only maximized state (bitmasks 2 and 4) to be a maximized window. I would suggest the next logical step (for a user) from a bitmask of 2 or 4 to be 6.

The positioning of the window in this circumstance could be considered a bug, as the position is restored to the last remembered co-ordinates prior to the vertical or horizontal maximize is triggered. This results in the majority of the window now being off screen (especially if horizontally tiled at the bottom of the screen - it is nearly 100% off screen), or at the top of the screen (the title bar is now under my panel requiring an ALT + LEFT CLICK to move the window).

So from the above, I guess I am really suggesting a modification in behaviour as follows:
From step 9 above - clicking the maximize button on a window that is only maximized in one direction (bitmask 2 or 4) should change state to maximized (bit mask 6).
From step 5 above - dragging a maximized (bitmask 6) window should change state to normal (bitmask 0) as it does, but if that drag continues to a screen edge, then a state change to vertically or horizontally mazimized should trigger (bit masks 2 or 4).

Of course, if these state changes are not possible (due to limitations of some sort), then may I suggest the state change to normal (bitmask 0) should also trigger a smart placement of the window either t...


Created attachment 5502
Fix ToggleMaximize fn when window is solely maximized verticaly or horizontaly


I've made this patch when I worked on my custom package. This should fix this issue.

The problem seem to come from to the ToggleMaximize function which do not maximize window when they are partially maximized horizontally or vertically.

Created attachment 5548
Fix ToggleMaximize fn when window is solely maximized verticaly or horizontaly

I found another related issue:

When the user try to restore maximized window that was previously tiled, the previous position was not restored correctly.

The new patch also fix this issue.

Yvan Masson (yvan-masson) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Thank you very for working on this issue.

I just reported it on Ubuntu Launchpad:

Thanks again for your time and work,

Yvan Masson (yvan-masson) wrote :

Thanks for the fast answer !
I did the link with upstream, where it seems they have a working patch.

I finally had time to look at this patch and test it out. It works great and fixes both issues in question.
Thanks for doing the hard work, Cédric!

Changed in xfwm4:
importance: Unknown → Low
status: Unknown → Fix Released

Actually the described behaviour was on purpose but I understand it was confusing users so it's fine to change that.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xfwm4 - 4.11.3-0ubuntu1

xfwm4 (4.11.3-0ubuntu1) vivid; urgency=medium

  * New upstream release.
    - Fix maximizing vetically or horizontally tiled windows. LP: #1397922
    - Revert "Experiment with button events." LP: #1394439
    - Use source indication in activate window. LP: #1292122
    - Determine the maximum host name length correctly. LP: #1233107
  * Drop 0001-fix-fullscreen-qt4-behavior-bug-8563.patch,
    02-remove-unused-maximize-button.patch, fixed upstream
 -- Jackson Doak <email address hidden> Sun, 15 Feb 2015 06:24:16 +1100

Changed in xfwm4 (Ubuntu):
status: New → Fix Released

*** Bug 8766 has been marked as a duplicate of this bug. ***

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.