Bug 429171

Summary: wayland: window rules, no titlebar and frame, won't auto-apply
Product: [Plasma] kwin Reporter: Duncan <1i5t5.duncan>
Component: rulesAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: herzenschein, isma.af, kynde, nate
Priority: NOR Flags: 1i5t5.duncan: Wayland+
1i5t5.duncan: X11-
Version: git master   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Other   
Latest Commit: Version Fixed In: 5.22.90

Description Duncan 2020-11-15 20:45:26 UTC
No-titlebar rules apply when setup, but don't apply to new windows.

Try this on wayland:

1. Have kpat or ksudoku or konsole running.

2. Setup a window rule for it.

3. Set no titlebar and frame, force.

4. Hit apply and watch the titlebar disappear, confirming that the rule matched, but leave the rules window open.

5. Quit the matched-window and restart it.

6. Watch the titlebar show up along with the new window, despite the "force" no-titlebar rule!

7. Back in the rules window, do something to activate the apply button again (toggling no-titlebar yes>no>yes works).

8. Hit apply and watch the titlebar disappear again.

9. Try fiddling with the match if you want.  I can't get it to apply to new windows unless perhaps it's so broad it'll apply to most/all windows (didn't actually try that).

10. Despite that, rule clauses such as size apply to new windows even while no-titlebar is ignored.

Conclusion: "Force" no-titlebar doesn't force it, at least for kde/wayland windows.  FWIW, neither does apply initially.  However, force *DOES* still seem to work for gtk2-based X windows (like claws-mail).  So it's either kde/qt specific or wayland-specific.


This is live-git frameworks/plasma/apps using the gentoo/kde overlay.  Qt 5.15.1. Just switching to wayland so I'm not sure if it's a regression there, but it seems to be fine on X.
Comment 1 Duncan 2020-11-15 20:58:11 UTC
FWIW tried firefox now too (couldn't shut it down before submitting the initial report), AFAIK the only non-kde thing I have that does a true wayland window, and same broken behavior.  So it appears no-titlebar rules are broken on new wayland windows regardless of whether the windows are qt/kde or gtk basis, while X windows appear to work fine.
Comment 2 Duncan 2020-11-16 18:38:30 UTC
Addendum:  I just discovered that if the match includes title and it's set to substring, while the initial window won't trigger the rule (even if it's a match), but when the title changes (from a substring that matches and should trigger but hasn't, to a different substring that matches), the rule will then be triggered.

If the rule includes both size and no-titlebar clauses, at the title-change trigger the no-titlebar part will trigger but that won't trigger a re-application of the size rule, so then the size is no longer what's set, despite it being in the same rule.  However, if the title changes again, triggering another re-match, since the no-titlebar is already applied, on the second rematch the size will again be forced to the set size.

So the rules are getting applied, but only on /change/, in this case, when the title  changes, triggering a new match on title substring.  Maybe the title match on substring condition is tested /after/ the no-titlebar clause is applied, so at first the no-titlebar clause isn't applied because the match hasn't been fully tested yet?  I believe that would create this behavior as only the title substring change would then trigger the match.
Comment 3 Thiago Sueto 2020-11-21 21:07:54 UTC
I can partially reproduce:

1) Window rules are not remembered after closing <-- 100% reproducible with Qt/KDE and GTK3 apps

2) Force titlebar is remembered for GTK2 apps (tried Claws) <-- Cannot reproduce

3) If includes title, rule works after updating title <-- Cannot reproduce

Operating System: openSUSE Tumbleweed 20201119
KDE Plasma Version: 5.20.80
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.1
Kernel Version: 5.9.8-2-default
Comment 4 Thiago Sueto 2020-11-22 01:14:16 UTC
I tested this on KDE Neon Unstable as well, I experienced the same behavior as comment 3.
Comment 5 Duncan 2020-11-24 09:49:38 UTC
Adding flags +wayland -X11, plus this reply...

(In reply to Thiago Sueto from comment #3)
> I can partially reproduce:
> 
> 1) Window rules are not remembered after closing <-- 100% reproducible with
> Qt/KDE and GTK3 apps

Thanks.

> 2) Force titlebar is remembered for GTK2 apps (tried Claws) <-- Cannot
> reproduce

Hmm.  I wonder if it's working here for claws due to the title update thing?  Do you have a mail account setup in it?  Presumably it starts with a generic title and updates it to include the default email account.  That could trigger the title update...

The other thing... your claws is still gtk2/X-based, coming up on wayland via xwayland, right?  Mine is.  Last I looked into it the claws folks were working on gtk3 and presumably native wayland support with it, but that was probably 6 months or a year ago.  I've not looked at it since, and definitely not since switching to kde/plasma-wayland.  But if they've updated and the openSUSE tumbleweed build is gtk3/native-wayland that might explain the difference.

Definitely more testing required for X/gtk2/etc to see what the difference is here.  I just tried xev, being the one X-based app I could think of off the top of my head, and couldn't get the titlebar to force off for it, but it's "strange" in that the window-rules detection couldn't find a window-class for it, and of course it doesn't appear to change window title so I can't test that part of it.  I'll have to try some others...

> 3) If includes title, rule works after updating title <-- Cannot reproduce

Hmm.  That's pretty solid here.  In fact, for one thing I run here, a text-based pdmenu in a konsole window, FWIW, due to this bug I'm actually having to deliberately script a title change via konsole/xterm escape sequences in ordered to trigger the detection and turn off the titlebar.[1]

But if my theory above that my seeing claws obey no-titlebar rules, possible because of a title change I wasn't aware was happening, is correct, then if a title change isn't triggering no-titlebar rule enforcement for you, it would explain that too.

Meanwhile, another development, but I'll put that in a different comment.

---
[1] pdmenu was designed as a text-based menu and pops up in the middle of the terminal.  It has customizable colors, and between them, setting konsole command-line switches for no toolbars/tabbars/scrollbars, and using a custom konsole color-scheme with a 100% transparent background (the menu itself has a background color set so it's not transparent, but the rather bigger konsole window it's appearing in is), I can make it appear as if the relatively small text-based menu is popping up by itself, not in the much bigger konsole/terminal window it's actually in -- as long as the titlebar doesn't appear to destroy the illusion.
Comment 6 Duncan 2020-11-24 10:09:43 UTC
After yesterday's update, things improved incrementally.  I'm not sure what exactly triggered the improvement, but...

kwin seems to notice changes in windows and reapply its rules more often now, often triggering no-titlebar if it's set, when it wouldn't before.

My /theory/ is that it's noticing when window titles are set, even if they don't actually change from whatever they were set to before, now, whereas before, it would only notice changes if the window title actually changed, not if it was set to the same value it had before.

Noticed in kpat and ksudoku, which start with a titlebar now despite a window rule turning it off for them, but which switch to no-titlebar mode, for instance when I start a game.  While that happened before if the window title changed, now two reevaluations seem to be triggered, the first of which turns off the titlebar but doesn't reset the window size resulting in a shorter window than the set size because it's accounting for the titlebar which isn't there now, the second of which resets the size to that set by the rule as well.  Before, it was only one triggered reevaluation.  I can _guess_ that the one trigger sets the title to the same value it had before so it didn't trigger before, leaving on the trigger that actually changed the title, while now they both trigger.  But of course since the title doesn't change with the one trigger, it's difficult to /prove/ that, leaving me /guessing/ as to the reasons for the now observed second observed trigger.

And while I did read the git log for kwin and some of the updated frameworks (as I routinely do), no single commit log leapt out at me as the reason for the improvement.  But it's nice to have, regardless. =:^)
Comment 7 Duncan 2020-11-24 21:15:07 UTC
(In reply to Duncan from comment #5)
> (In reply to Thiago Sueto from comment #3)
> > 2) Force titlebar is remembered for GTK2 apps (tried Claws) <-- Cannot
> > reproduce

> Definitely more testing required for X/gtk2/etc to see what the difference
> is here.

OK, tried generic X (xeyes, xev) and gtk2/X (claws, gimv/gimageviewer, pan, xscreensaver-demo), and everything X-based I tried seemed to "just work" with the no-titlebar-and-frame rule clause, including vlc with its qt5 interface which despite being qt5 is still X (wmctrl, an X-based window-manager scripting tool, still lists vlc, while it doesn't list native-wayland windows).

If it's not for you, it may be the difference between my live-git build (as of two days ago now) and your AFAIK release-version tumbleweed and neon (to a lessor extent if you're trying neon unstable?).

It's the native wayland stuff that kwin is failing to properly assert the no-titlebar-and-frame clause on, and that's the case whether it's gtk3/python3.8/wayland (solaar), qt5/python3.8/wayland (hplip's device-manager), gtk3/wayland (firefox), or kde5/plasma5/qt5/wayland (konsole, kpat and ksudoku most thoroughly tested here).  Tho firefox and hplip's device manager, plus konsole, kpat and ksudoku, tend to title-change, triggering the settings that way, while solaar doesn't.

So the bug must be in kwin's handling of the wayland protocol, since it affects all wayland-based windows I've thrown at it be they qt5 or gtk3 based, while it does /not/ affect the qt5 but still X vlc or any other X-based windows I've thrown at it.

Which is interesting since kwin, unlike some of the other wayland compositors, does server-side (aka compositor-side) decorations, so it *has* to know the titlebar parameters and be in control over whether the titlebar and frames appear since it draws them!

I still believe it's some sort of race between the titlebar/frame drawing code and the window detection, now known to be limited to the wayland-native code path, since the other rule clauses generally apply fine, and the titlebar/frame clause does too, if a title change comes in (and apparently now if a title set comes in even if it just sets the same title as it had before, see comment #6).

Well, with that recent improvement being two days old now, I need to do another update and see if there's further improvements.  Maybe I'll get lucky and be able to say it's fixed.  There's another bug of mine, bug #429588 (that one window-rules kcm but not wayland-related), resolved/fixed that I've not yet picked up, too. Actually, Nate Graham, who resolved the bug, said that one was fixed right about as I was filing it.=:^)
Comment 8 Ismael Asensio 2021-09-03 17:40:51 UTC
*** Bug 436854 has been marked as a duplicate of this bug. ***
Comment 9 Bug Janitor Service 2021-09-04 01:19:02 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1373
Comment 10 Ismael Asensio 2021-09-04 12:49:55 UTC
Git commit bb0f749ee7d1589048eebe1620f53978bbf4681e by Ismael Asensio.
Committed on 04/09/2021 at 10:47.
Pushed by meven into branch 'master'.

xdgshellclient: Fix "noBorder" rule on initialization

The check for this rule was missing on window initialization,
so on Wayland it wasn't being applied until something would
trigger the check again.
FIXED-IN: 5.22.90

M  +1    -0    src/xdgshellclient.cpp

https://invent.kde.org/plasma/kwin/commit/bb0f749ee7d1589048eebe1620f53978bbf4681e