Colored window borders and title bar disappearing

[Robbains]

Qubes OS version Xen_version 4.8.5-23.fc25 Linux 4.19.147-1.pvops.qubes.x86_64 Qubes Os release 4.0 (R4.0)

Affected component(s) or functionality missing window borders under xfce4, I can't reduce, enlarge or close windows, and I can only use one window at a time

Solutions you've tried I tried this function and it solved my problem for good. xfwm4 --replace

Relevant documentation you've consulted doc.ubuntu-fr.org/xfce

[marmarek]

Do you know what action triggered this issue? Check coredumpctl command output in dom0, do you see xfwm4 listed there? If so, can you copy output of coredumpctl info xfwm4 here? See here how to copy text from dom0.

[yg-ht]

Just thought I would let you know that I have experienced the same issue and solution and it is fixed persistently across reboots.

A bit more background / info in case it is useful for diagnosis:

Laptop was working fine yesterday, no updates / config changes completed and powered off as normal. This evening turned on and after login this problem was immediately present. No known trigger events. It is worth noting that I don't usually have a background image, it is just grey when I know I should have a slightly different grey with the Qubes logo on it. When this issue started I did have a background. As soon as I execute the command originally reported as the solution, my window gained decoration and a 3mm grey border appeared which then "overwrites" the proper background image if you move the window around. I have had this problem a few times on previous installs (all R4), but previously I got frustrated with it and just reinstalled the whole OS.

I ran coredumpctl which shows a problem dated early last month related to xfce4 but nothing about xfwm4.

I do have contents in .xsession-errors though which does include references to xfwm4:

generating cookie with syscall
generating cookie with syscall
generating cookie with syscall
generating cookie with syscall
xfce4-session: No SSH authentication agent found
gpg-agent[4073]: WARNING: "--write-env-file" is an obsolete option - it has no effect

(xfce4-session:4067): xfce4-session-WARNING **: gpg-agent returned no PID in the variables
gpg-agent[4074]: gpg-agent (GnuPG) 2.1.13 started
xscreensaver:   signal: 0: child pid 4133 (xscreensaver-systemd) exited abnormally (code 1).
sys-firewall: Starting GUI
sys-net: Starting GUI
sys-usb: Starting GUI
sys-vpn: Starting GUI
vault: Starting GUI
sys-firewall: Sending monitor layout
sys-net: Sending monitor layout
sys-usb: Sending monitor layout
sys-vpn: Sending monitor layout
vault: Sending monitor layout
xfsettingsd: No window manager registered on screen 0.

(xfsettingsd:4077): xfsettingsd-WARNING **: Failed to get the _NET_NUMBER_OF_DESKTOPS property.
xfce4-panel: No window manager registered on screen 0. To start the panel without this check, run with --disable-wm-check.

(wrapper-2.0:4245): Gtk-WARNING **: Negative content width -3 (allocation 1, extents 2x2) while allocating gadget (node butt$
disp4936: Starting GUI
disp4936: Sending monitor layout

(xfce4-terminal:4789): Gtk-WARNING **: Allocating size to GtkScrollbar 0x6109cbc22550 without calling gtk_widget_get_preferr$

(xfce4-terminal:4789): Gtk-WARNING **: Allocating size to GtkScrollbar 0x6109cbc22550 without calling gtk_widget_get_preferr$

(xfwm4:5005): xfwm4-WARNING **: Unmanaged net_wm_state (window 0x800004, atom "_NET_WM_STATE_FOCUSED")
disp453: Starting GUI
disp453: Sending monitor layout

(xfwm4:5005): GLib-CRITICAL **: Source ID 1224 was not found when attempting to remove it

(xfwm4:5005): GLib-CRITICAL **: Source ID 1258 was not found when attempting to remove it
gpg-agent[4074]: SIGTERM received - shutting down ...
gpg-agent[4074]: gpg-agent (GnuPG) 2.1.13 stopped

** (xss-lock:4113): CRITICAL **: X connection lost; exiting.

[DemiMarie]

Does this go away if the “Hide frame of windows when maximized” option (under System Tools > Window Manager Tweaks > Accessibility) is unchecked?

[yg-ht]

Thankfully it doesn't happen all the time, just the odd occasion, once every few months. It hasn't happened again (to me at least) since my last post. Gut feel is that it isn't related as none of the windows in question are maximised, however, should I get a recurrence I will test and report back.

On 1 January 2021 19:47:30 GMT, Demi Marie Obenour notifications@github.com wrote:

Does this go away if the “Hide frame of windows when maximized” option (under System Tools > Window Manager Tweaks > Accessibility) is unchecked?>

-- > You are receiving this because you commented.> Reply to this email directly or view it on GitHub:> https://github.com/QubesOS/qubes-issues/issues/6152#issuecomment-753373458

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[deeplow]

I do not have this issue, but I was able to reproduce it by running multiple times xfwm4 --replace. But I only got it to fail once. Seems to be a timing thing. Here's the shell sessions that lead me from a "window-border" state into a "no window-border" state:

[user@dom0 ~]$ xfwm4 --replace
Waiting for current window manager (Xfwm4) on screen :0.0 to exit: Done

(xfwm4:11803): xfwm4-WARNING **: Unmanaged net_wm_state (window 0xa00004, atom "_NET_WM_STATE_FOCUSED")
core^C
(xfwm4:11803): GLib-CRITICAL **: Source ID 4994 was not found when attempting to remove it
[user@dom0 ~]$ xfwm4 --replace

(xfwm4:11856): xfwm4-WARNING **: Unmanaged net_wm_state (window 0xa00004, atom "_NET_WM_STATE_FOCUSED")
^C
(xfwm4:11856): GLib-CRITICAL **: Source ID 300 was not found when attempting to remove it
[user@dom0 ~]$ xfwm4 --replace
Waiting for current window manager (Xfwm4) on screen :0.0 to exit:............... Failed

(xfwm4:11864): xfwm4-WARNING **: Previous window manager (Xfwm4) on screen :0.0 is not exiting

(xfwm4:11864): xfwm4-WARNING **: Could not find a screen to manage, exiting

The output seems to be in line with that of a user experiencing a similar issue (on the forum).

[deeplow]

A user mentioned this has happened to them on 3 or 4 different laptops with no modifications to dom0. It happened every few months. I think this may be alarming given the disabling of window borders constitutes a security issue (loss of the trusted path).

(see original comment here)

[andrewdavidwong]

I think this may be alarming given the disabling of window borders constitutes a security issue (loss of the trusted path).

This seems more like just a bug (at worst, a potential DoS) than a real security problem. If the window borders disappear, the user immediately knows that he can no longer identify security domains by their colored window borders. The user now knows to read the title bars to see which qube each window belongs to and to reboot/relog at the next available opportunity in order to restore the window borders. It only becomes a security problem if, upon the borders disappearing, the user suddenly makes the illogical leap to assuming that all windows must now belong to the same security domain. I don't think it's realistic that a human would do this.

[deeplow]

It only becomes a security problem if, upon the borders disappearing, the user suddenly makes the illogical leap to assuming that all windows must now belong to the same security domain. I don't think it's realistic that a human would do this.

I would disagree. The title bars disappear as well as can be seen here. The security issue comes in when a user has a job and needs to use the computer, regardless.

Although immediately obvious, it possible the user is under job pressure and needs to use the system anyways. Or is just procrastinating a full system reinstall. During that time-frame, the inability to identify which window is which may make it possible for a phishing attack, for example to occur.

Yes, the user is to blame in that case. But the human factor needs to be considered in these situations as well for a system to be secure.

Anyways, that's my 2 cents.

[deeplow]

reboot/relog at the next available opportunity in order to restore the window borders

Quoting from a user:

And the problem persists upon reboot. My only solution is complete reinstall.

[andrewdavidwong]

reboot/relog at the next available opportunity in order to restore the window borders

Quoting from a user:

And the problem persists upon reboot. My only solution is complete reinstall.

Ah, in that case, I agree it's much more serious, since the user has no reasonable way to work around it on a regular basis.

A different user had previously reported above that it is temporarily fixed across reboots.

[andrewdavidwong]

It only becomes a security problem if, upon the borders disappearing, the user suddenly makes the illogical leap to assuming that all windows must now belong to the same security domain. I don't think it's realistic that a human would do this.

I would disagree. The title bars disappear as well as can be seen here. The security issue comes in when a user has a job and needs to use the computer, regardless.

Although immediately obvious, it possible the user is under job pressure and needs to use the system anyways. Or is just procrastinating a full system reinstall. During that time-frame, the inability to identify which window is which may make it possible for a phishing attack, for example to occur.

Yes, the user is to blame in that case. But the human factor needs to be considered in these situations as well for a system to be secure.

I don't think anyone denies this. We agree that it's important to consider the human factor, and we do. The problem is that you're expanding the scope of "security issue" to include everything that could, through human behavior, become related to security, whereas we use it to refer mainly to the types of security vulnerabilities that get CVEs, XSAs, and QSBs, along with closely-related issues of this sort.

By your type of reasoning, for example, Qubes not working on certain popular laptops would be a security issue, since it leads to those laptop owners using less secure OSes. Likewise, Qubes not coming pre-installed with everyone's favorite apps would be a security issue, since it leads some users to reduce their own security by trying to install untrustworthy apps or install trustworthy apps incorrectly. Similarly, Qubes not creating automatic external backups would be a security issue, since users are notoriously bad at making regular backups (even when provided with the tools to do so) and are therefore exposed to data loss. Since Qubes is a security-oriented OS, you can turn almost anything into a security issue through this type of reasoning, at which point the term loses much of its technical meaning and usefulness.

In this particular case, if it were to turn out that an attacker can force the window borders to disappear, for example, I think that would constitute a security issue. (It would still be a form of DoS, so not nearly as serious as the attacker being able to change the window border colors, for example. Nonetheless, since the window borders are handled in dom0, any ability for an adversary to manipulate them would be quite serious.)

As it stands, what we seem to have is a very frustrating and disruptive bug, but the security implications of this bug appear to be no different than a bug (not an attack) in which the computer suddenly reboots without warning. In other words, if the user were to immediately reboot whenever the window borders disappear (which would, again, be extremely frustrating and disruptive), then it seems to me that the security implication would be the same as if the bug itself were that of (non-adversary-controlled) spontaneous reboots.

[deeplow]

I totally agree with what you said above.

As it stands, what we seem to have is a very frustrating and disruptive bug, but the security implications of this bug appear to be no different than a bug (not an attack) in which the computer suddenly reboots without warning.

Exactly. Except the persistence of this issue across multiple devices the user reported. If this is indeed non-adversary controlled it's just an annoying thing but if there is any way this DoS could be triggered then it should be investigated. One thing I can think of for example (and certainly the Qubes devs though about this) is spamming the GUI protocol in a ways that the window manager can't handle.

[DemiMarie]

I wonder if this is due to XFCE being misconfigured. If it is, wiping out all XFCE settings should fix it.

[DemiMarie]

@deeplow @yg-ht Can this problem still be reproduced? If not, https://github.com/QubesOS/qubes-desktop-linux-xfce4-xfwm4/pull/14 might have fixed it.

[deeplow]

I haven't been able to reproduce it (with xfwm4 --replace). But I'm not sure it's because of the fix. It might have fixed. The issue is that we never got a reliable method to detect if this had been fixed or not.

[DemiMarie]

Closing for now, but please reopen if a reproducer is found.

[SCBuergel]

I have these issues for a week or so on Xfce 4.14 on Qubes 4.1.2. I already tried the xfwm4 --replace in dom0 but it just reset a bunch of shortcuts and didn't fix the issue. In fact that attempt of a solution made Qubes almost entirely broken for me because right now I cannot move windows around anymore and a window that I opened at a later time stays on top, even if it is not in focus anymore. Edit: it gets unbearably annoying, I only have one desktop (used to be 4) and I cannot open certain programs anymore - e.g. trying to open the Window Manager Tweaks simply does not start/show the program anymore. I assume it's lost somewhere else but I cannot see it. Even when that's the only program I open. Restarting the system changes nothing.

I am quite sure my "trigger event" was when I set some shortcuts for docking windows left, right, top, bottom, fullscreen similar to what I had on Ubuntu.

[bramhaag]

I experienced a similar issue after rebooting, without changing anything. My laptop was in sleep mode previously, and for whatever reason would not wake up. It made Qubes entirely unusable, as I could not move any windows and was unable to interact with any terminal of any qube.

The issue was persistent across reboots, but xfwm4 --replace fixed it for me.

[acessonegado]

I experienced a similar issue after rebooting, without changing anything. My laptop was in sleep mode previously, and for whatever reason would not wake up. It made Qubes entirely unusable, as I could not move any windows and was unable to interact with any terminal of any qube.

The issue was persistent across reboots, but xfwm4 --replace fixed it for me.

This happened with me right now, i rebooted my machine and when i logged in everything was gone.

QubeOS Version: R4.2.1 Kernel: 6.6.29-1.fc37

• the colored borders were gone
• the title bar of the windows disappeared
• I was unable to move the windows
• impossible to maximize/minimize any window
• the buttons were gone
• the windows were always open at the top (without the buttons)
• right click on desktop does not open menu

Almost getting crazy trying to fix it, nothing was working, until I found the solution thanks to @Robbains i could fix it using his solution:

xfwm4 --replace

Reading some posts here I saw that some commented about the option to hide the borders when a window is maximized under System Tools > Window Manager Tweaks > Accessibility and it was precisely after checking the Hide frame of windows when maximized” box that this problem happened to me.

since this post, im now editing it because today even with the 'hide the borders' deactivated i had the same issue, fixing it with xfwm4.

[DemiMarie]

@acessonegado can you run coredumpctl?

[realGWM]

I have the same problem now. xfwm4 --replace neither fixes the issue not displays any errors/warnings (the only message from it is about waiting for current window manager to exit and then Done).

I don't have xfwm4 listed in coredumpctl.

I've unchecked "Hide frame of windows when maximized" and it didn't fix the issue.

Deleting files from ~/.cache/sessions/ didn't help either.

I managed to fix it by disabling "display compositing" in Window Manager Tweaks.

The problem is trivially reproducible now - enabling compositing makes borders disappear. I'd love to help investigating the issue, so please let me know what should I do, what logs to check, etc.

There is also a problem now that some parts of the top panel are using light theme, while rest of the system uses a dark one.. Any ideas how to solve that? Nevermind, the top panel has its own settings, and the problem is fixed by enabling "use dark theme" property there.