Unable to switch to different application when focus is on VSCode

[KevinKZ]

Expected behaviour

While focus is on VSCode (i.e. typing in the editor), switching to a different application - either via alt-tab (or whatever shortcut) or by clicking on the app in the window list applet in mate-panel - should restore/bring-up the other application.

Actual behaviour

While focus is on VSCode (i.e. typing in the editor), switching to a different application - either via alt-tab (or whatever shortcut) or by clicking on the app in the window list applet in mate-panel - does not restore/bring-up the other application. Instead, the name of the application in the mate-panel's window list becomes bold and no further change.

The only way to switch to the application is to click on the titlebar of VSCode. When I do so, switching to a different application works as intended and brings up the other application to the front. It seems like VSCode/Electron is holding focus hostage. However, clicking on the titlebar of VSCode seems to bring the focus back to its intended behavior. It seems like the issue is isolated to the non-titlebar section of VSCode. The titlebar of VSCode is a custom style and doesn't use the regular framing like the other windows. Others in my team experience the same issue. I have only experienced this with VSCode so far.

However, this is not a VSCode bug as far as I can tell. When I switch to a different wm (i.e. icewm) I'm able to get the expected behavior. It's not a mate-panel or window list applet bug either because it happens when trying to alt-tab switch to a different application too. There was one case where I started a new session of VSCode and somehow I was able to consistently get the expected behavior. After I closed that session and started a new one, the bug was back. I don't think it's specific to VSCode either because I have seen old threads online describing the same bug seen while using other applications.

Steps to reproduce the behaviour

Open VSCode for Linux - might need to be SLES 12.5 but not 100% sure - and start typing in the editor. Try to switch to another open application by clicking in the window list of mate-panel or alt-tabbing into it.

MATE general version

MATE DE version 1.22.1

Package version

Marco version 1.22.1

Linux Distribution

SLES 12.5

Link to bugreport of your Distribution (requirement)

N/A

---

Seems like the issue revolves around how Marco restores/brings windows to the front when switching to another application. There's got to be something unique about VSCode in this case that's preventing Marco from behaving as expected. Is there a section of the code I can look into to see what could be possibly affecting this and do some debugging on my end? Any suggestions or ideas on what to do to narrow this down?

[lukefromdc]

This is an ugly bug, but I can't easily work on it due to having no Electron apps installed, having never worked with it, etc. Can someone on the team who has ever worked with VSCode or at least with Electron have a look at this?

[KevinKZ]

Installing VSCode and running it to recreate this bug should be pretty straightforward. Is there something I can try in the meantime on my end to figure this out?

[lukefromdc]

If you have compiz, see if this happens with it running.

[lukefromdc]

Not going to install VScode here. I don't consent to Microsoft's license, and especially not on my production system. I notice their privacy statement alllows data collection-and I have sensitive data on this machine, so that's a hard NO. With this sort of software, one mistake in turning off telemetry and antifeatures and they have your data.

I have never developed on virtual machines and in fact never used one. Maybe someone that does can work on this, then trash the VM in question when they are done.

[KevinKZ]

No compiz here (IT restrictions) but I’ve tried marco with both --composite and --no-composite (or whatever the args are actually called) and the bug is present in both.

Do you happen to know which function/part of the code is responsible for bringing up a window? I’m assuming in the case when I click on the buttons in the window list applet in mate-panel, the former sends some kind of notification/calls marco to restore the respective window. Is that correct?

[lukefromdc]

Honestly I don't know much about that part of the code and have never worked on it. Those who've done the heavy lifting on Marco would know. All I've done with Xorg window managers (mostly in compiz) is get GtkFrameExtents working for windows with shadows and transparent edges, fix some bugs related to stacking order and backdrop theme support, some hippi work in compiz that I use but was never merged, these sort of things. Never worked with the core code to draw a window

[KevinKZ]

Not going to install VScode here. I don't consent to Microsoft's license, and especially not on my production system. I notice their privacy statement alllows data collection-and I have sensitive data on this machine, so that's a hard NO. With this sort of software, one mistake in turning off telemetry and antifeatures and they have your data.

I have never developed on virtual machines and in fact never used one. Maybe someone that does can work on this, then trash the VM in question when they are done.

I understand. I work with sensitive data too but our farm is firewalled so nothing's going out that's not supposed to (take that, Microsoft). My case is probably a challenging circumstance to replicate to reproduce the bug. I can track down the other threads I’ve seen online where their circumstances might be easier to replicate. Would that help?

[lukefromdc]

I really don't know, as this one is too far outside the range of my experience. Will leave this for others

[KevinKZ]

Honestly I don't know much about that part of the code and have never worked on it. Those who've done the heavy lifting on Marco would know. All I've done with Xorg window managers (mostly in compiz) is get GtkFrameExtents working for windows with shadows and transparent edges, fix some bugs related to stacking order and backdrop theme support, some hippi work in compiz that I use but was never merged, these sort of things. Never worked with the core code to draw a window

Ah I see. Would you be willing to bring this to the attention of someone who's more familiar with the core code?

[lukefromdc]

That should happen automatically by our posting here. I do not have memorized who does what.

[KevinKZ]

Gotcha! Hopefully we can get to the bottom of this. Thanks for the help

[raveit65]

I can't reproduce the issue with VS Code.
When i am editing a file with VS Code i am able to switch to another application with alt-tab.
With fedora 38 and VS Code installed from microsoft repository for rpm based linux.

Version: 1.83.1
Commit: f1b07bd25dfad64b0167beb15359ae573aecd2cc
Date: 2023-10-10T23:45:31.402Z
Electron: 25.8.4
ElectronBuildId: 24154031
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 6.5.7-200.fc38.x86_64

So what is different to your setup?

[KevinKZ]

Hmm that's a good question. Might be an SLES 12.5 thing then. Did you use the same mate/marco version?

My current workspace setup is a Linux VDI on an SLES 12.5 server. We use Exceed ETX to connect which gives us the Linux Environment GUI.

I have another workspace setup where the Linux VDI uses CentOS (not sure if marco is the wm there or not; have to check) but no such issue there.

I'm thinking it's either related to the virtualization or the OS. I can check on the former in my other setup to eliminate that variable. For the latter, do you happen to have a SUSE 12.5 VM to try this on?

I'll try to get a video of the behavior when it happens again; my current open instance of VSCode is not exhibiting this bug. I don't know what changed now; this is the seond time in two days where this bug doesn't show up. I just know that I've done a lot of experimenting trying to fix this in the past few days and it involved a lot of restarting marco and mate-panel and switching back and forth btw other wm's.

The only othr thing I can think of is that whenever I relaunch marco from the terminal (marco --replace &) I get the following messages whenever I click on VSCode's titlebar (and only VSCode's titlebar):

"Window manager warning <window_id_pointing to vscode> last_user_time (%u) is greater than comparison timestamp (%u). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around..."

The weird thing is that the comparison timestamp is a much larger value than the last_user_time and (assuming it's unix timestamp) it points to year 2080. I don't know if this is a good lead or not. Like I said, my current VSCode instance doesn't exhibit this bug but I also didn't relaunch marco from the terminal so I can't see these messages. Is there somewhere else they're written to perhaps? I want to check if these messages show up currently that the bug isn't happening. This way, if these messages don't show up, then we know that the bug and these messages are related. If they do show up (in logs or something alike) then we know the bug is not related to these warnings and they can be ignored.

[raveit65]

MATE general version

MATE DE version 1.22.1

Package version

Marco version 1.22.1

I would say your Mate and marco version is pretty obsolete, reached EOL since years and will never get updates anymore. Current stable version is 1.26.x

Hmm that's a good question. Might be an SLES 12.5 thing then. Did you use the same mate/marco version?

Nope, as fedora maintainer i push only supported and latest 1.26.x packages to fedora and redhat family.

Maybe you try out Mate 1.26.x packages to verify the issue?

[KevinKZ]

That's a fair statement. Unfortunately, the OS/Mate version is out of my control. Our IT just upgraded our farm to SLES 12.5 a few months ago and I believe the next step is SLES 15 in a year or so which I’m assuming would come with a more recent MATE environment.

I’m not any expert on Linux admin but is it possible for MATE/Marco to be updated standalone or does that need a whole distro upgrade?

Is it possible for me to build the latest version of marco and install it standalone without root privileges? If I could have it as a local binary and run "marco_new_version --replace &" would that be a valid way of checking if a newer version 1) has this fixed and 2) can replace the older version locally?

[raveit65]

I have another workspace setup where the Linux VDI uses CentOS (not sure if marco is the wm there or not; have to check) but no such issue there.

You need to install Mate-1.26.x from epel8 repository for centos -stream8.
centos7 with epel7 use an old version of Mate

I'm thinking it's either related to the virtualization or the OS. I can check on the former in my other setup to eliminate that variable. For the latter, do you happen to have a SUSE 12.5 VM to try this on?

No, sorry i do not use SUSE.

[raveit65]

Is it possible for me to build the latest version of marco and install it standalone without root privileges? If I could have it as a local binary and run "marco_new_version --replace &" would that be a valid way of checking if a newer version 1) has this fixed and 2) can replace the older version locally?

Try out to compile marco by hand. Not sure if it works with mate-1.22 build dependencies.

[KevinKZ]

Just a quick follow up on this; I wasn’t able to compile a newer version of Marco and make it work with the current SLES version dependencies but I have discovered that this bug might be machine dependent.

In my flow, I launch VSCode on a remote SLES host from my local host. Depending on host availability, VSCode can end up on a different host each time. After cycling through a few different remote hosts, I found one where this bug wasn’t occurring. I confirmed by ending the VSCode session and resubmitting a new session to the same host. I could not recreate the bug there. I then launched VSCode on a different host and I could recreate the bug there.

I’m going to be running some more trials to determine if it really is machine dependent or if I got lucky. If I can recreate the same behavior (i.e. no focus bug) on more than one host, we can safely deduce it's something to do with a specific type of remote host environment.

If that's the case, what are some things you suggest I check across the "good" and the "bad" remote hosts to narrow down what exactly could be causing this?