Commit 9331a6f1 introduces a weird bug
Distribution: Void Linux
DE: xfce
DM: LightDM (v1.32) with lightdm-gtk3-greeter (v2.0.8) and light-locker (v1.9.0) <- those are the respective "current versions" available on Void Linux
The list of available users at the login screen is disabled via the following 2 entries in /etc/lightdm/lightdm.conf.d/50-lightdm.conf
greeter-hide-users=true
greeter-show-manual-login=true
When libxfce4ui was updated from v4.18.3 to v4.18.4 a weird bug appeared.
Normal (expected) behavior (with libxfce4ui v4.18.3):
At the login screen with the above settings one has to put in the user name as well as the password to log in. No matter if the login happens after boot, logout or resume after standby (s3).
Unexpected behavior with libxfce4ui v4.18.4 installed:
Now, at login after resume from standby (s3), the user name is already or still (however one wants to look at it, or depending on what the code does in the background) typed into the text field for entering the user name, and the cursor is blinking in the password field instead of the user name field.
For the last few months I just downgraded to libxfce4ui v4.18.3 to avoid that bug. However, it comes with a visible downside: The login process takes way longer than with v4.18.4.
I already filed an issue report with LightDM with no results. As I'm just a normal user (and can't really read code and also don't know what happens in the background when I put the system into standby and then resume it again, i.e. which package is responsible for doing what and esp. which package for some reason puts the user name into the text field when it should be empty), I don't know which package is ultimately the culprit, libxfce4ui, LightDM, lightdm-gtk3-greeter or light-locker - or some combination of those, or a completely different one.
Today I set out to find the change that introduced the bug for me. Thankfully, relevant changes between v4.18.3 and v4.18.4 only were done to libxfce4ui/xfce-screensaver.c, and luckily, I picked the last commit (b07efc88) that didn't come with that bug by chance, which I, of course only learned after testing the following commit (9331a6f1).
Replacing libxfce4ui/xfce-screensaver.c from the one in the release package of v4.18.4 with the one from commit b07efc88 results in a "bug-free" version of v4.18.4, using libxfce4ui/xfce-screensaver.c from commit 9331a6f1 results in a "buggy" version of v4.18.4.
To test it even further, I built a version of v4.18.4 with libxfce4ui/xfce-screensaver.c from the final commit (0f4eb4af) with the changes from 9331a6f1 reverted back to the respective code from commit b07efc88. But that also resulted in a "buggy" version of libxfce4ui v4.18.4.
So, commit 9331a6f1 is the first commit that introduced the bug, but later commits also changed code that also lead to this bug independently from commit 9331a6f1. I didn't check any further which changes (or commit) that might be.
D-bus handling sounds even to a "user, not coder" like myself like a big(ger) deal and thus important. So, I can't judge if the code could be adjusted to avoid this bug, or if one other package (e.g. one of the ones I listed above) that hasn't had a new release since libxfce4ui v4.18.4 was released needs updating.
As stated above, I have no clue what happens at the moment of suspend to s3 or resume from s3 to login screen. Thus I have no clue how to determine what goes differently between the two versions of libxfce4ui, v4.18.3 vs. v4.18.4.
Any help would be greatly appreciated!