! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
GTK+ 3 applications with header bars raise on click despite correct setting


Description Octavio Alvarez 2015-02-02 18:07:56 CET
GTK+ 3 applications that have header bars raise on click despite having disabled the "Raise window when clicking inside application window".

Example: Gedit 3.14 raises when I click the text I'm editing. Mousepad behaves ok.

Other settings I have, just for reference:
* Focus model; FFM.
* Automatically raise when receiving focus: disabled.
* Focus stealing prevention: enabled.
* When a window raises itself: do nothing.
* Raise windows when any mouse button is pressed: disabled.

Comment 1 Olivier Fourdan editbugs 2015-02-02 18:18:54 CET
Unfortunately not something that can be fixed, it's the applications that raise themselves, not the window manager. So not a bug in xfwm4.
Comment 2 Olivier Fourdan editbugs 2015-02-02 18:23:52 CET
Ah wait, I take that back!
Comment 3 Olivier Fourdan editbugs 2015-02-02 18:27:57 CET
It is not the application window raising itself, it's the window manager, but since those are client side decorations (aka CSD) windows, they are basically undecorated by the window manager so there is no title bar, it's all the application managing itself.

As a result, the window manager cannot tell if the click is inside the application or the title bar, since there's none.

So if that particular setting was applied to CSD yo would not be able to raise the window with the mouse at all. So to prevent this, that particular setting is ignord on undecorated windows.

So cannot fix.
Comment 4 Octavio Alvarez 2015-02-02 19:31:30 CET
Sounds like an a priori workaround. There is still raising by Alt+Click, the window button, the window selector, Alt+Tab, etc, two of those are mouse-only, and another one is primarily a mouse solution.

Just like it happened with you, it happened with me: I thought the app was raising itself. Xfwm special-casing of these windows is unexpected.

Considering it's the application developer that decided not to have WM decorations for his application, it's the application that should be affected by that, not the user. As of right now, the WM is the one not behaving as I configured it. For example, I can't do copy+pasting from gedit the same way I do with other applications.

As of right now, this is a double-bug: the application has a limitation by not offering regular WM decorations (for whatever reason) and the WM is not honoring user configuration.

With this, users would be able to report bugs to the application themselves.

Or a midway solution, to have an option: "[ ] Raise client-decorated windows on click" as a suboption. I was going to suggest "Raise borderless windows on click" but borderless could also mean override_redirect.

Bug #11498

Reported by:
Octavio Alvarez
Reported on: 2015-02-02
Last modified on: 2016-02-08


Olivier Fourdan
CC List:
0 users




Additional information