! 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 !
Firefox and Chromium with their own titlebars do not obey no-raise-on-click s...


Description Marcel Partap 2020-04-06 22:51:04 CEST
[Sooo... This has bothered me for quite a while, and now that I'm procrastinating on adding synapse workers support to our university matrix instance which is growing massively at the moment, I have tried to dig to the bottom of this issue.]

When these browsers use normal window manager title bars, they will not raise by a click on the window itself, only if explicitly clicking on the titlebar. With their custom implementation of a titlebar however, a window clicked will raise blatantly, counteracting this setting.
In chromium, this setting can be toggled by right-clicking the titlebar and selecting "Use system title bar and borders", in firefox by setting `browser.tabs.drawInTitlebar` to `false`in `about:config`.
https://bugs.chromium.org/p/chromium/issues/detail?id=318937#c65 mentions the `_MOTIF_WM_HINTS` property, but I could not replicate the above behaviour on another window by setting the flag with `xprop -f _MOTIF_WM_HINTS 32c -set _MOTIF_WM_HINTS "0x2, 0x0, 0x0, 0x0, 0x0"`, although toggling the aforementioned browser settings indeed does toggle that third flag for the browser windows.
For now, turning off the browsers own title bar implementations is a valid and welcome workaround.
Comment 1 Olivier Fourdan editbugs 2020-04-07 08:34:01 CEST
Those apps use client side decorations, meaning they draw their own decorations, not the window manager.

Of course, “no raise on click” works only on the client area, clicking on the title bar should still raise the window. But without decoration, there is no title bar from the window manager, it's all the client window there.

Therefore, in theory, with those apps you would not be able to raise the window with “no raise on click”, never, as there is no window manager title bar.

To prevent this, xfwm4 will allow raise-on-click for those apps that have no decorations.

That's on purpose and not something I am willing to break.
Comment 2 Marcel Partap 2020-04-07 10:26:54 CEST
Ok that's very valid reasoning, thanks for explaining. However, I think this should go next to that tick box in the XFWM settings dialogue..
Comment 3 Marcel Partap 2020-04-07 10:35:15 CEST
 .. also, these apps could still be raised ALT-TABbing to them..
Comment 4 Git Bot editbugs 2020-04-07 19:59:48 CEST
Olivier Fourdan referenced this bugreport in commit 0da6c4be6acc950ccdf0091376ed35204101031e

Revert "device: Use standard grabs for passive button grabs"

Comment 5 Git Bot editbugs 2020-04-07 19:59:50 CEST
Olivier Fourdan referenced this bugreport in commit 0c376d254293ca52162bcddf4bcfa5908fb28e4c

device: Check standard passive button grabs

Comment 6 Olivier Fourdan editbugs 2020-04-07 20:02:37 CEST
Oops wrong bug! Sorry.
Comment 7 olaf 2020-04-09 19:18:17 CEST
(In reply to Git Bot from comment #5)
> Olivier Fourdan referenced this bugreport in commit
> 0c376d254293ca52162bcddf4bcfa5908fb28e4c

[   63s] device.c: In function 'xfwm_device_grab_keycode':
[   63s] device.c:504:1: warning: control reaches end of non-void function [-Wreturn-type]

This becomes a hard error later on in package builds.
Comment 8 Git Bot editbugs 2020-04-11 17:59:21 CEST
Olivier Fourdan referenced this bugreport in commit 1bdc36fbdda0cd53c5f50744cd6c2c3bdef00dbb

device: Check standard passive button grabs


Bug #16649

Reported by:
Marcel Partap
Reported on: 2020-04-06
Last modified on: 2020-04-11


Olivier Fourdan
CC List:
0 users




Additional information