Lock screen crash message is vague

[MatusGuy]

Describe the issue

When the lock screen program crashes, an explosion image pops up, and supposedly nothing works until restarting the lock screen program. This image does not provide any information about what just happened or why it happened, and therefore confuses the user to no end.

Additional information

Despite being given the opportunity to show text, the author of the session lock plugin decided to only show an explosion emoji: https://github.com/WayfireWM/wayfire/blob/master/plugins/protocols/session-lock.cpp#L190-L193

Related: #2911, #2998

[ammen99]

Well, I wouldn't be opposed to adding a fuller text with an explanation, PRs welcome :)

[ziadkhouri]

If someone would like to draft the text, I'd be happy to have a go at coding it :)

[MatusGuy]

I don't know.... Maybe something like

The lock screen program has crashed.

with instructions on how to recover it

[AKArien]

I will say, while very confusing, i found it hillarious when it happedend to me :) but probably because i didn’t have any important work unsaved

[Secret-chest]

If text is added, then it should be translatable. Please update me if someone is introducing the text so that I can help make it translatable (I have introduced translations, but only for the option descriptions).

@ziadkhouri

[marcusbritanicus]

What would it take to add loginctl support? That is, the user logs in via tty, and issues the command loginctl unlock-session <sess-id>, and wayfire unlocks the screen. This of course is to be used when the lockscreen crashes.

If there is some way for a plugin to tell wayfire that it can unlock the screen and terminal the screen lock session, I think we could add a simple plugin that could listen to org.freedesktop.login1 and ask wayfire to release the lock.

[soreau]

What would it take to add loginctl support? That is, the user logs in via tty, and issues the command loginctl unlock-session <sess-id>, and wayfire unlocks the screen. This of course is to be used when the lockscreen crashes.

If there is some way for a plugin to tell wayfire that it can unlock the screen and terminal the screen lock session, I think we could add a simple plugin that could listen to org.freedesktop.login1 and ask wayfire to release the lock.

As @trigg pointed out to me, you can set an always_binding via the command plugin to relaunch the lock screen application. I think this thread is more about users understanding what happened, in case their computer displays an explosion emoji.

[ammen99]

What would it take to add loginctl support? That is, the user logs in via tty, and issues the command loginctl unlock-session <sess-id>, and wayfire unlocks the screen. This of course is to be used when the lockscreen crashes.

If there is some way for a plugin to tell wayfire that it can unlock the screen and terminal the screen lock session, I think we could add a simple plugin that could listen to org.freedesktop.login1 and ask wayfire to release the lock.

We could add ipc methods or signals or whatever you need to write such a plugin. But indeed, this issue is specifically about the error message presented to the user.

[Secret-chest]

What would it take to add loginctl support? That is, the user logs in via tty, and issues the command loginctl unlock-session <sess-id>, and wayfire unlocks the screen. This of course is to be used when the lockscreen crashes.
If there is some way for a plugin to tell wayfire that it can unlock the screen and terminal the screen lock session, I think we could add a simple plugin that could listen to org.freedesktop.login1 and ask wayfire to release the lock.

As @trigg pointed out to me, you can set an always_binding via the command plugin to relaunch the lock screen application. I think this thread is more about users understanding what happened, in case their computer displays an explosion emoji.

For some reason, once gtklock has crashed, it will crash immediately should I restart it. I can open swaylock though from a TTY and it will let me pass.

[marcusbritanicus]

What would it take to add loginctl support? That is, the user logs in via tty, and issues the command loginctl unlock-session <sess-id>, and wayfire unlocks the screen. This of course is to be used when the lockscreen crashes.
If there is some way for a plugin to tell wayfire that it can unlock the screen and terminal the screen lock session, I think we could add a simple plugin that could listen to org.freedesktop.login1 and ask wayfire to release the lock.

As @trigg pointed out to me, you can set an always_binding via the command plugin to relaunch the lock screen application. I think this thread is more about users understanding what happened, in case their computer displays an explosion emoji.

Sorry... I completely skipped this part: We can show the text:

"The lock screen application has crashed. To unlock the screen, restart the program or unlock the session using loginctl unlock-session <session-id>"

Or as @soreau suggested in the chats, 🔒💥

[ziadkhouri]

I'd be reluctant to mention loginctl specifically. Although it would be helpful to suggest a resolution, there are plenty of distros that don't use systemd.

Perhaps best keep it to:

"The lock screen application has crashed 🔒💥"

?

[MatusGuy]

I'd be reluctant to mention loginctl specifically. Although it would be helpful to suggest a resolution, there are plenty of distros that don't use systemd.

In my opinion, the resolution shouldn't get completely omitted to systemd users just because there are non-systemd users out there. Therefore, you could add a clause, and end up with something along these lines:

The lock screen program has crashed!
If this system is using systemd, then you can run `loginctl unlock-session <sess-id>` in a terminal to unlock the session manually and bypass the lock screen program.

You could also dynamically add this message if systemd is detected. However, I do not know how trivial that is to implement.

Despite all of this... honestly... is this loginctl thing even a solution?? I remember logging into a tty when this happened. The whole session just crashes, and kicks me back to the display manager. Lol. Isn't this a big issue with Wayland in general? Excuse my lack of knowledge on this subject. Either way, for cases like these, this solution wouldn't be particularly useful, unless the message explicitly states to not use a tty, and instead to use an ssh, for example.