Visual artifact 1px vertical white line right side of the wallpaper with Ambiance/Radiance

[Tarmo Turunen]

After manually upgrading from 20.04 LTS to 22.04.1 LTS I find that there is a 1px wide vertical white line on the desktop that appears whenever an application has focus. It is on the right side of the monitor, covering the background wallpaper but not the menu.

Workaround: in Displays, change scale to something else than 100% and then change back to 100%. That white vertical line will stay at the former 100% window size location until the Settings window is closed. It disappears when the Settings is closed.
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu82.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
DisplayManager: gdm3
DistroRelease: Ubuntu 22.04
InstallationDate: Installed on 2018-04-27 (1570 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
Package: gnome-shell 42.2-0ubuntu0.2
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 5.15.0-46.49-generic 5.15.39
RelatedPackageVersions: mutter-common 42.2-0ubuntu1
Tags: wayland-session jammy
Uname: Linux 5.15.0-46-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo www-data
_MarkForUpload: True

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Libera.chat.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1986450/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Daniel van Vugt (vanvugt)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:

apport-collect 1986450

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

[Tarmo Turunen (dimarchi)]

apport information

[Tarmo Turunen (dimarchi)]

apport information

[Tarmo Turunen (dimarchi)]

apport information

[Tarmo Turunen (dimarchi)]

apport information

[Tarmo Turunen (dimarchi)]

apport information

[Tarmo Turunen (dimarchi)]

apport information

[Daniel van Vugt (vanvugt)]

Thanks. Please try removing your extensions in case they are the cause:

  cd ~/.local/share/gnome-shell/
  rm -rf extensions

and then log in again.

[Tarmo Turunen (dimarchi)]

Done. There is no change. The artifact is still present.

[Daniel van Vugt (vanvugt)]

In the past I had seen a 1px gap down the right side of the wallpaper on Intel, but I think that was only during desktop zoom and I can't reproduce it today. Whatever the cause was might still be present and might only be manifesting with AMD graphics. Just a theory.

[Tarmo Turunen (dimarchi)]

That could very well be the case. It does not appear when the desktop is initially loaded, but shortly after a refresh(?). If I keep the second monitor (TV) active, the scaling workaround does not work - the lines on both monitors come back when set back to 100% scale. If I click the desktop the line disappears from the monitor that was clicked - and comes back once the desktop is no longer focused. An annoying little thing that I'm sure is equally annoying to figure out.

[Daniel van Vugt (vanvugt)]

Can you attach a photo or video of the issue?

[Tarmo Turunen (dimarchi)]

Picture one, default when the desktop is no focused.

[Tarmo Turunen (dimarchi)]

Picture two, after the desktop was scaled to 125% and then back to 100%, and the Settings window is not closed, yet (the white line disappears after the Settings window is closed).

[Tarmo Turunen (dimarchi)]

Single monitor examples. The same happens when I activate the second monitor, with the exception that the white lines are both on the second display before closing the Settings (if I recall correctly). Would you like pictures of the two monitor setup, as well? Or do these two pictures demonstrate the artifact well enough so that they are not needed?

[Daniel van Vugt (vanvugt)]

Thanks, that's enough info.

My immediate thought is that it might relate to mutter's background rendering code which aggressively tries to limit the number of wallpaper pixels it redraws each frame. Maybe there's an off-by-one mistake in that code.

[Tarmo Turunen (dimarchi)]

I would not know. Nevertheless, I consider this bug report as a heads up in case you encounter it or something similar in the future. It is nothing critical, and the workaround does work, even though applying it every time I log in to Ubuntu will probably get tedious in the long run. Does this even affect others? No idea.

[Daniel van Vugt (vanvugt)]

I've not seen any other reports of this bug.

If it is mostly only visible on AMD graphics and less than 6% of Ubuntu users are using AMD graphics, intersected with the small proportion of users who are willing to report bugs instead of ignoring them, it's a small intersection so unsurprising it took this long to be reported.

I need to switch to AMD to work on another bug soon so I will check on this one too.

[Tarmo Turunen (dimarchi)]

An update since I have a new computer with a fresh, clean install of Ubuntu 22.04.3 LTS...this may very likely be a theme issue. It is not present when using the default theme. It appears when trying to change the Applications theme to - for example - Ambiance (the one I would prefer).

Consider this solved?

[Daniel van Vugt (vanvugt)]

If the bug still occurs with any theme then we should keep it open.

[Egmont Koblinger (egmont-gmail)]

I can reproduce the problem on two computers, both running fully-updated 24.04 beta.

For me, the bug appears if all of these circumstances are met:
- /org/gnome/desktop/interface/gtk-theme is Ambiance or Radiance
- one of the windows is focused
- the Desktop Icons NG (DING) extension is enabled in extension-manager

The first two matches earlier observations here, the third one looks like new information.

As you toggle the DING extension, this vertical 1px wide bar quickly rushes to/from the right edge of the screen. It suggests that it's not that the background isn't drawn properly, it's rather that DING explicitly draws this line on top of it (and shows a brief animation when getting enabled/disabled).

This also aligns with the observation that a window needs to be focused -- probably if focus is taken away from windows by clicking on the background then DING receives the focus, and apparently it's DING's unfocused state combined with Ambi/Radi themes that results in this glitch.

I'm almost certain that this is a bug either in DING or in the Ambi/Radi themes.

It's probably not related to the graphics card. One of these computers has an NVidia (nouveau driver), the other one has ATI Radeon. Scaling is probably unrelated, too. The glitch is seen on both Xorg and Wayland.

[Egmont Koblinger (egmont-gmail)]

Looks remotely related: https://askubuntu.com/questions/927893/white-line-on-left-of-ubuntu-launcher-when-desktop-icons-enabled

[Egmont Koblinger (egmont-gmail)]

I've modified /usr/share/themes/Ambiance (recursively), search-replacing all the "1px" to "10px", and (after logging out and back in) the line at the desktop's right edge looks about 10px wide.

So we're on the right track.

[Egmont Koblinger (egmont-gmail)]

It's /usr/share/themes/{Amb,Rad}iance/gtk-3.20/gtk-widgets.css line 18:

  .background:backdrop {
      color: @backdrop_fg_color;
      box-shadow: inset -1px 0 shade (@bg_color, 0.94);
                        ^^^^
  }

Change that to 0 (or I guess you could remove the entire line or even the entire segement).

(I'm not a gtk css expert by any means, I don't know if this is _the_ proper way to solve this issue, nor whether it causes problems elsewhere.)

[Jeremy Bícha (jbicha)]

Wow, I didn't realize that people were still trying to use Ambiance and Radiance (from source package ubuntu-themes) with Ubuntu 24.04 LTS.

Would you like to submit a patch and subscribe ubuntu-sponsors?

[Egmont Koblinger (egmont-gmail)]

Without root access (or being worried of an update overwriting the changes), this is how I could fix it as a user.

I've placed this in my ~/.config/gtk-3.0/gtk.css file:

  window.desktopwindow.background:backdrop {
    box-shadow: none;
  }

Don't ask why it's gtk-3.0 and not 3.20 or 4.0, I have no clue. [Update: I've figured out, gnome-shell-extension-desktop-icons-ng is a gtk3 app.]

The "window.desktopwindow" selector is something I've found in gnome-shell-extension-desktop-icons-ng's source. It's a more specific selector than the one in the theme, hence takes precedence over that. Without this selector they would be of the same precedence, and for some reason the one in the theme is used, the one in the user's config is ignored. And GTK doesn't seem to support "!important".

This extra selector luckily gives some confidence that the rule probably doesn't have an effect on others. (However, the disclaimer from my previous comment still applies.)

In extension-manager toggle the said extension back and forth to apply the change.

[Egmont Koblinger (egmont-gmail)]

> Wow, I didn't realize that people were still trying to use Ambiance and Radiance (from source package ubuntu-themes) with Ubuntu 24.04 LTS.

I'd love to switch to Adwaita or Yaru, but I prefer to have dark window header and light window contents, and I haven't found yet how to do it in those.

(I'm also in the process of evaluating whether I want to leave Unity behind and switch to GNOME or its Ubuntu desktop flavor... that's how I came across this issue.)

> Would you like to submit a patch and subscribe ubuntu-sponsors?

The thing is, I'm not confident that I'm doing the right thing and not causing side effects elsewhere. I'm even unsure at this moment whether the fix needs to go into the theme, or the extension should ship the override.

I'd much rather prefer if someone familiar with GTK theming/CSS could take over from here.

[Jeremy Bícha (jbicha)]

Ambiance/Radiance are basically unmaintained so if there's a bug it would probably be easier for you to propose a fix then trying to find someone else to do it.

If you have concerns about the extension, I suggest filing an upstream issue:
https://gitlab.com/rastersoft/desktop-icons-ng/-/issues

[Egmont Koblinger (egmont-gmail)]

Let's see what DING devs think: https://gitlab.com/rastersoft/desktop-icons-ng/-/issues/315

[Egmont Koblinger (egmont-gmail)]

DING developer's response is basically that they clear the "decorated" property of the window, and the theme should handle that.

Based on this, I think the correct solution for the Ambiance/Radiance themes is to further restrict the offending block with the ".decorated" selector, i.e.

  .background.decorated:backdrop {
      color: @backdrop_fg_color;
      box-shadow: inset -1px 0 shade (@bg_color, 0.94);
  }

or for the user's own gtk.css to select for its negated ":not(.decorated)" for the workaround:

  .background:not(.decorated):backdrop {
      box-shadow: none;
  }

[Egmont Koblinger (egmont-gmail)]

> .background.decorated:backdrop {

This still doesn't feel entirely good. The background can be applied to a window, in which case it needs to be restricted to the .decorated property; but I presume it can also be applied to many other GTK widgets in which case it shouldn't be restricted, at least in order not to change the current behavior because I don't know how to test any change.

So if I'd like to perform the smallest possible change, the smallest possible impact of the change (preferably: no other change than fixing this bug) then I'd need to select for "either window.decorated or something non-window", which I'm not sure how to express in CSS (at least not in a single step).

Maybe leave the first block untouched, and then revert its effect in the next rule for undecorated windows (effectively moving the above-proposed user workaround into the main theme, restricted to the element being a window).

So the theme itself would go like (the first block is unchanged, the second one is newly added):

  .background:backdrop {
      color: @backdrop_fg_color;
      box-shadow: inset -1px 0 shade (@bg_color, 0.94);
  }

  window.background:not(.decorated):backdrop {
      box-shadow: none;
  }

Dunno how much it makes sense. Would really love to get it reviewed by a CSS expert :)