Bug#1073788: gimp: whole-system froze when adjusting threshold

[Simon McVittie]

Control: reassign -1 sway 1.7-6
Control: retitle -1 sway: whole system froze when adjusting threshold in gimp

On Tue, 18 Jun 2024 at 13:13:44 +0200, Manny wrote:
> As soon as the slider is moved, *both* screens on a dual headed
> machine go black for ~1½ seconds then pop back on. GIMP is only ever
> present one of the two displays, never spread out. On one occassion,
> the system froze for a few seconds before the cursor could move
> again. On another occasion, the keyboard and mouse were permanently
> frozen. I walked away from the machine for ~5 minutes or so to give it
> time to unfreeze, but it never unfroze. I was ultimately forced to
> physically force a power down of the whole system. It would have been
> catastrophic if I had unsaved work in any application.

It should not be possible for GIMP to achieve this sort of freeze of
the compositor even if it wanted to, so I'm reassigning this to sway
(I've assumed that you're using the version of sway from Debian 12,
please correct the version metadata if that's wrong).

Please check for messages in the systemd journal at the time of this
freeze - I suspect you will see some sort of warning or error from
sway, Xwayland and/or the kernel.

> There is also a security problem here. In principle, what if a user
> were to leave GIMP to enter a password in another app?  GIMP should
> not have access to the keyboard when it is not in focus. This security
> flaw is not in GIMP, but rather in Wayland or Sway and GIMP is merely
> demonstrating how an unfocused app can eavesdrop on the keystrokes.

If the compositor (in your case that's sway) gives GIMP access to the
keyboard at times when you think it should not have access, then that's
also not a GIMP bug: it's the compositor that controls what information
is available to applications, not the other way around.

    smcv