gnome-terminal darkened by visual bell during screensaver

[Walter]

[ Impact ]

 * Compositor based visual effects while screensaver is running can render
   some windows unusable. One such instance is visual bells in gnome-terminal
   will leave the window darkened if they occur during that time. This is due
   to the compositor skipping but not reverting the transition.

 * The backported change restores the initial state when effects transitions
   are skipped (e.g. while screen is locked).

 * Although the bug has been reported against gnome-terminal, it could
   affect other applications or extensions making use of opacity transitions.

[ Test Plan ]

 * launch a fresh instance:
   lxc launch images:ubuntu/24.04/desktop testvm --vm
   lxc console d --type vga

 * gsettings set org.gnome.desktop.wm.preferences visual-bell-type frame-flash;
   gsettings set org.gnome.desktop.wm.preferences visual-bell true;
   xdg-screensaver activate; sleep 2; echo -e \\a;

 * The terminal window should not remain opaque when exiting the screen saver.

[ Where problems could occur ]

 * The opacity transition functionality is used in a handful of applications,
   by the gnome desktop and by extensions.

 * This change is very small in scope, but could affect the window-flashing
   functionality on gnome mutter. It possibly could interfere with
   window opacity as it is one of the affected attributes of the flash
   transition.

 * The patch has already been included with mutter 47+ and newer Ubuntu
   releases for more than a year without issue.

[ Original Descriptiption ]

Problem: visual bell during screensaver turns terminal very dark with no remedy.

Reproducing:

- Settings -> Accessibility -> Hearing -> Visual Alerts -> On
  (Flash the entire Window)

- Open a gnome-terminal

- Ensure volume is not muted

- type: xdg-screensaver activate; printf '\a'

- Wake up the screensaver, and notice that the window in which there was a bell, is darker.

Tested and reproduced on:

- Jammy (2024-06-15)
- Noble (2024-07-04)

---------------------
Original ticket below
vvvvvvvvvvvvvvvvvvvvv

========
Symptoms
========

Sometimes, when coming back to my laptop, and unlocking an existing GNOME session, I find that my gnome-terminal has turned very dark. I have found no triggers (other than session unlock) and no fixes to undo the darkness.

It looks like this:

https://junk.devs.nu/2024/lp2064716-gnome-terminal-turned-dark/gnome-terminal-very-dark-on-the-right.png
( https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2064716/+attachment/5774287/+files/gnome-terminal-very-dark-on-the-right.png )

The window on the right is the one I found after unlocking my GNOME session. The window on the left was a second terminal I started, which has the normal brightness.

Using some color picking, I can say that the brightness has been reduced by 70%-85%.

Here's an animation of the window:

https://junk.devs.nu/2024/lp2064716-gnome-terminal-turned-dark/gnome-terminal-turned-very-dark.webm
( https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2064716/+attachment/5774288/+files/gnome-terminal-turned-very-dark.webm )

The video shows:
- The dark window in a smaller state;
- settings are opened, and switched to bright colors;
- both the good and the bad terminals get lighter, but the bad terminal is still way too dark;
- moving the window to the right shows a glitch in the glitch where the bottom-most row has normal colors.

========
Versions
========

- Ubuntu Jammy 22.04 (many versions)
- gnome-terminal 3.44.0-1ubuntu1
- libmutter 42.9-0ubuntu7

I thought it might be a Wayland thing, but I switched back to Xorg recently and the problem wasn't gone. I've not seen this bug with Focal. And my colleagues haven't seen the bug either.

========
Followup
========

I have no idea where to look further. I did some probing with xprop on the window, that gave me no useful info, and may likely not be relevant as Wayland is also affected.

Any suggestions to get to the bottom of this is appreciated.

Unfortunately, I don't know how to trigger the bug. I always have terminals open, and only 1% of the time (ball park) when unlocking does this occur.

Let me know. Cheers!
Walter Doekes

[Egmont Koblinger (egmont-gmail)]

Just wondering, does it help if you disable transparency (in Preferences -> Unnamed profile -> Colors)?

[Walter (wdoekes)]

Good question. I did in fact try that:

- In Unnamed profile -> Colors;
- the "Use transparency from system theme" was ticked, but there is no transparency.
- I unticked it, and and clicked "Use transparent background", and then it was transparent -- still dark though.

I also tried:

xprop -f _NET_WM_WINDOW_OPACITY 32c -set _NET_WM_WINDOW_OPACITY 0x7fffffff

Which made it 50% transparent. And then 0x0 which hid the window entirely and then 0xffffffff to make it opaque again.

Alas, no change in darkness.

[Walter (wdoekes)]

Well. I got some luck in reproducing. Got it twice today (23:14:03 and 23:40:51), and these log messages were seen right around when the screen locked:

$ journalctl --user -S '-2 days' | grep CLUTTER -A2

mei 02 19:10:18 wortel.kiwi gnome-shell[21305]: clutter_timeline_set_auto_reverse: assertion 'CLUTTER_IS_TIMELINE (timeline)' failed
mei 02 19:10:18 wortel.kiwi gnome-shell[21305]: clutter_timeline_set_repeat_count: assertion 'CLUTTER_IS_TIMELINE (timeline)' failed
mei 02 19:10:18 wortel.kiwi gnome-shell[21305]: invalid (NULL) pointer instance
mei 02 19:10:18 wortel.kiwi gnome-shell[21305]: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
--
mei 03 23:14:03 wortel.kiwi gnome-shell[21305]: clutter_timeline_set_auto_reverse: assertion 'CLUTTER_IS_TIMELINE (timeline)' failed
mei 03 23:14:03 wortel.kiwi gnome-shell[21305]: clutter_timeline_set_repeat_count: assertion 'CLUTTER_IS_TIMELINE (timeline)' failed
mei 03 23:14:03 wortel.kiwi gnome-shell[21305]: invalid (NULL) pointer instance
mei 03 23:14:03 wortel.kiwi gnome-shell[21305]: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
--
mei 03 23:40:51 wortel.kiwi gnome-shell[362660]: clutter_timeline_set_auto_reverse: assertion 'CLUTTER_IS_TIMELINE (timeline)' failed
mei 03 23:40:51 wortel.kiwi gnome-shell[362660]: clutter_timeline_set_repeat_count: assertion 'CLUTTER_IS_TIMELINE (timeline)' failed
mei 03 23:40:51 wortel.kiwi gnome-shell[362660]: invalid (NULL) pointer instance
mei 03 23:40:51 wortel.kiwi gnome-shell[362660]: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

In fact, I know what I was doing:

2024-05-03 23:40:45 sleep 5; start-vpn
2024-05-03 23:42:44 history | tail -n10

Somewhere around 23:40:48 I locked the screen, and at 23:40:50+ code started running that triggers a (maybe) GUI notification popup.

Full disclosure, that VPN notification popup is mine:
https://github.com/ossobv/openvpn-u2f-setup/blob/main/openvpn-u2f-ask-password

I'm not entirely sure what the sequence of events is here, but those dbus/glib interactions around the time when things break are too much of a coincidence. This also explains why I'm the only one having this issue.

mei 03 23:40:51 wortel.kiwi openvpn-u2f-ask-password[364589]: DEBUG: Got pyinotify event
mei 03 23:40:51 wortel.kiwi openvpn-u2f-ask-password[364589]: DEBUG. is_in_screensaver org.gnome.ScreenSaver True
mei 03 23:40:51 wortel.kiwi openvpn-u2f-ask-password[364589]: DEBUG. Ignoring ask-password request because in screensaver mode
mei 03 23:40:51 wortel.kiwi gnome-shell[362660]: clutter_timeline_set_auto_reverse: assertion 'CLUTTER_IS_TIMELINE (timeline)' failed
mei 03 23:40:51 wortel.kiwi gnome-shell[362660]: clutter_timeline_set_repeat_count: assertion 'CLUTTER_IS_TIMELINE (timeline)' failed
mei 03 23:40:51 wortel.kiwi gnome-shell[362660]: invalid (NULL) pointer instance
mei 03 23:40:51 wortel.kiwi gnome-shell[362660]: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
mei 03 23:42:18 wortel.kiwi openvpn-u2f-ask-password[364589]: DEBUG: Re-reading /run/systemd/ask-password
mei 03 23:42:18 wortel.kiwi dbus-daemon[362531]: [session uid=1...

[Egmont Koblinger (egmont-gmail)]

Sorry if I wasn't clear. I didn't mean what if you toggle transparency after the bug manifests.

What I meant was: What if you completely disable transparency, use gnome-terminal without enabling that feature. Maybe even restart gnome-terminal, just in case. Does the bug still occur then?

If so, the next step could be to debug what if you remove the transparency feature from the codebase. It's a downstream Ubuntu patch, not part of official upstream gnome-terminal. Maybe the bug is related to (triggered by) that patch even if the setting is disabled, but doesn't occur with official gnome-terminal.

However, after all, I think it's a problem with the window manager / compositor, rather than the app requesting transparency. An app, even if explicitly wanted to, should not be able to trigger such behavior.

Anyway, I'm afraid I won't be able to further assist you or investigate this issue, we'll need an Ubuntu developer (I'm not one) to join.

[Walter (wdoekes)]

Egmont, thanks for your replies.

I've been running this for a few days:

```
gnome-terminal (3.44.0-1ubuntu1wjd0+ubu22.04) jammy; urgency=medium

  * Disable transparency patches:
    - 0001-Restore-transparency.patch
    - 0001-screen-window-Extra-padding-around-transparent-termi.patch
    - scrollbar-background-theming.patch
    An attempt to figure out how/why the terminal goes dark sometimes:
    https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2064716
    (LP: #2064716)
```
That is, the Jammy gnome-terminal, but without three patches which seemed to relate to transparency.

It hasn't improved things. The darkness bug still exists.

I also haven't found any clues of applications (mis)behaving in the same timeframe. The CLUTTER_IS_TIMELINE assertions still look most related to the issue at hand.

Trying to see if I can remove/disable some daemons that I don't need that are active at the same time...

[Walter (wdoekes)]

Okay. Finally found the reproducer: it's the visual bell during screensaver.

Attaching a screenshot.

Reproducing:

- Settings -> Accessibility -> Hearing -> Visual Alerts -> On
  (Flash the entire Window)

- Open a gnome-terminal

- type: xdg-screensaver activate; printf '\a'

- Wake up the screensaver, and notice that the window in which there was a bell, is darker.

Note that changing the Visual Alert to "Flash the entire screen" fixes the issue.

It tried this just now on a different Ubuntu/Jammy, and the results are the same; 100% reproducible.

[Launchpad Janitor (janitor)]

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

[Walter (wdoekes)]

Should be fixed by:
https://gitlab.gnome.org/GNOME/mutter/-/commit/906920cb333486fd9ecd553cc819e2cd9799da6c

[Walter (wdoekes)]

This is still a thing. That commit exists in libmutter 0.47+, but Ubuntu Noble uses libmutter 0.46.

[Matthew Astley (mcra)]

[~wdoekes] spotted my dup

https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2113786/comments/17

[Nick Rosbrook (enr0n)]

I am able to reproduce on noble as well, with the small caveat that volume must be on. The patch referenced in #10 looks reasonable to SRU in my opinion.

[Simon Poirier (simpoir)]

I submitted SRU patch against salsa https://salsa.debian.org/gnome-team/mutter/-/merge_requests/161

[Daniel van Vugt (vanvugt)]

Fix committed, but it's likely we'll wait till next year to release it along with any other Mutter fixes that Noble needs. Also the SRU team is shutting down for the holiday period anyway (from yesterday until 6 January).