Window border corruption after changing display scale between 100% and 200% in Xorg

Tried modifying the source code of gnome-initial-setup, found that this issue cannot be reproduced, if the titlebar of the window (gis-assistant) is not set in the main (gis-driver) window.

I think this issue can be worked around in gis-assistant, but the root cause might be either gnome-initial-setup, mutter or libgtk-3

Yes I think it looks like a mutter bug judging by the video.

Mutter keeps multiple copies of window-related things, moreso on X11 where the server is a separate process with its own idea of how big a window is. That also means a window gets resized in multiple processes at slightly different times. So it's easy to mess up in mutter and get bugs like this (I have done in the past).

I suggest trying to find a generic app that upstream (Red Hat) will have as a test case. If you can do that then it should be reported to https://gitlab.gnome.org/GNOME/mutter/issues

Reported to upstream with stripped test case: https://gitlab.gnome.org/GNOME/mutter/-/issues/1875

Status changed to 'Confirmed' because the bug affects multiple users.

This bug is not limited to changing the scale from lower to higher and is not limited to shadows displaying garbage. It also occurs:

* when changing the scale from higher to lower
* infrequently when new windows or dialogs are created, particularly snap apps like nautilus or gnome-text-editor or modal dialogs such as e.g. evolution

Other effects in addition to shadows displaying garbage are:

* the window not capturing mouse events correctly, other windows below the garbage window capture the events
* the window not being able to capture focus, i.e. come to the front of other windows

The situation can be 'fixed' by maximizing + unmaximizing the window, users can TAB-select the window if it cannot be reached with the mouse.

(Summary from my duplicate bug report https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2023209)

Yes sometimes we need to oversimplify bug descriptions to ensure people can find and understand them.

I believe this is a general problem with the underlying X Window and Mutter actor getting out of sync, where one is still rendering (and interpreting input) at the old scale and the other expecting to render at the new scale.

It's more than 2 years after this bug was filed first. Does this mean that there is no interest in fixing the Ubuntu desktop? Is that even a mutter bug? Triaging was seemingly done under false assumptions about the boundaries of the bug. Any hints why this bug is mainly present in Snap apps?

I agree this is an ugly bug but since it's likely to happen at most once ever (assuming you don't change display scales often), it doesn't qualify for high priority compared to our other work. Still, this is open source and anyone is entitled to try and debug it and offer fixes.

It's not "mainly present in Snap apps". It's been known to occur in other (deb) apps from the beginning.

> likely to happen at most once ever

Come to think of it, most people changing display scale will never encounter the bug at all. Because most systems will get a Wayland session by default and Wayland is not affected. This bug only affects Xorg sessions. So that means some Nvidia systems, some virtual machines, and not much more.

1. This bug happens without screen scale changes, e.g. modal appointment reminder windows by Evolution regularly start in this screwed up state.
2. Switching screen scales is pretty normal for a production laptop that goes on and off external monitors, e.g. between working desk and commuter shuttle/ kitchen table. Not an unusual setup.
3. Snap apps *always* end up borked after screen scale changes, other apps sometimes, there is something with the snap apps that could be interesting to investigate, if anybody cared to investigate.
4. Xorg + Nvidia are pretty typical for many production laptops, e.g. for the rare tribe of engineers working with deep learning. Ubuntu is a typical operating system because it aligns well with the servers that are eventually used. This is certainly not everybody but a cool bunch.
5. There are many reasons why Wayland may not be appropriate for a laptop used for work, I found a list online https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277 and my personal thing would be: How to I ever get out of Libre Office (which hangs a lot for simple stuff like copy-pasting a table column) without xkill?
6. I strongly believe that the attitude "this is open source and anyone is entitled to try and debug it and offer fixes" is inappropriate and a weird kind of gate keeping that is toxic to open source projects. Open source is not open source and your expertise is not mine. I am a user of thousands of open source projects and I contribute to and maintain a couple of tens. I am an expert in my domain and I care for the open source projects that I can contribute to. I do not tell users to fix my bugs. I am not an expert in fixing novel window decoration bugs in Ubuntu, this is your domain, please take ownership of your bugs.

I spent a day on Wayland, and I found that parts of this bug are present on Wayland, though somehow less frequently, I could only trigger them with screen scale changes. Not all apps seem to be affected equally, but I can trigger it reliably with the Signal, Slack, git gui or gitk apps. Signal and Slack are snaps, git gui and gitk are installed via apt. Open the app, change screen scale from 200 to 100 or vice versa, see the mess. Scaling from 200% to 100%, these apps get a defunct window decoration that is out of sync and size with their content, the texture buffer is apparently full of random garbage that fills the holes. The effect is slightly different, depending on whether the app had been started at 100% or 200% screen scale.

Summary of this update: This bug affects both Xorg and Wayland with Ubuntu's Gnome standard distribution.

Thanks. I find it surprising there is a similar issue on Wayland. Maybe it is just a similar issue with a different root cause. Can you attach a screenshot or photo of the Wayland issue? Still, it might need a separate bug.