GNOME Bugzilla – Bug 781760
Don't disable extensions when screen is locked
Last modified: 2021-07-05 14:35:06 UTC
When logging back in after a screen lock GNOME Shell reloads all extensions. Depending on the computer speed and number of extensions, this can take several seconds. If someone really wants to save power, he should use suspend. This also causes some bugs with several extensions: * Pixel Saver (https://extensions.gnome.org/extension/723/pixel-saver/) needs to unmaximize, maximize all maximized Windows so that the caption stays hidden. This looks rather ugly. * System Monitor (https://extensions.gnome.org/extension/120/system-monitor/) loses its history, because it isn't running while the screen is lock. * App Indicators (https://extensions.gnome.org/extension/615/appindicator-support/) sometimes disappear because the programs are still running, but the DBus interface disappears during the lock. Extensions shouldn't appear on the lock screen though, see https://bugzilla.gnome.org/show_bug.cgi?id=686763
(In reply to Jan Niklas Hasse from comment #0) > Extensions shouldn't appear on the lock screen though, see > https://bugzilla.gnome.org/show_bug.cgi?id=686763 So you are saying that we should leave extensions enabled on screen lock, but somehow remove them from the lock screen? How do you imagine that to work? As far as I can see, we would need to rely on extensions themselves to handle screen lock correctly, which would likely result in a major break. So the most I see us doing would be to allow extensions to opt out of getting disabled automatically, not to stop doing it altogether.
Could not be locked the access to that extensions even they are loaded?
Sorry, I don't understand that suggestion.
The extension keeps loaded but their access will be locked, and a third person only can get info (as much) from extensions like system monitor (for instance), maybe that should be a extension's dev task though.
> So you are saying that we should leave extensions enabled on screen lock, but somehow remove them from the lock screen? How do you imagine that to work? The top panel on the screen lock could be a different panel. It already looks different and only includes the shutdown / volume indicator.
(In reply to Jan Niklas Hasse from comment #5) > top panel on the screen lock could be a different panel. It already > looks different and only includes the shutdown / volume indicator. I support that :D
(In reply to WyRe from comment #4) > The extension keeps loaded but their access will be locked Sorry, but that's hand-waving. What kind of "access" are you talking about? And what exactly do you mean by "locked"? Not to mention that it's generally not possible to know whether some code has been called from an extension or some other part of gnome-shell.
(In reply to Jan Niklas Hasse from comment #5) > > So you are saying that we should leave extensions enabled on screen lock, but somehow remove them from the lock screen? How do you imagine that to work? > > The top panel on the screen lock could be a different panel. It already > looks different and only includes the shutdown / volume indicator. OK, what about system modal dialogs or notifications then? Or any other change extensions may make that doesn't boil down to adding an icon to the top bar ...
> OK, what about system modal dialogs or notifications then? Or any other change > extensions may make that doesn't boil down to adding an icon to the top bar ... Good point. But most extensions only show modal dialogs when I click somewhere in their interface, which wouldn't show in the "lock screen panel".
(In reply to Jan Niklas Hasse from comment #9) > But most extensions only show modal dialogs when I click > somewhere in their interface, which wouldn't show in the "lock screen panel". Sure, but you are not asking to change the behavior for *most* extensions, but for *all* of them. *Most* extensions handle disable/enable correctly ;-)
You're right. Would you agree to enable a setting (in metadata.json?) for extensions to opt-out? Is there already a way for an extension to figure out if it gets disabled because of screen-lock or normally?
(In reply to Jan Niklas Hasse from comment #11) > Would you agree to enable a setting (in metadata.json?) for extensions to > opt-out? Let's say I could be convinced, though I'm a bit worried that in many cases it'll be used to just paper over bugs (from the examples cited above, only the systemMonitor one sounds like a genuine use case). > Is there already a way for an extension to figure out if it gets disabled > because of screen-lock or normally? Yes, but IMHO any extension that is caught gaming the system like that shouldn't pass review on extensions.gnome.org.
(In reply to Jan Niklas Hasse from comment #0) > * Pixel Saver (https://extensions.gnome.org/extension/723/pixel-saver/) > needs to unmaximize, maximize all maximized Windows so that the caption > stays hidden. This looks rather ugly. Filed as bug 781862 - we could have fixed that years ago if someone had bothered to file a bug instead of working around the issue :-(
One problem remains: > Depending on the computer speed and number of extensions, this can take several > seconds. @WyRe: You were the one on IRC asking about this, right? Could you post a list of the extensions you're using?
(In reply to Jan Niklas Hasse from comment #14) > One problem remains: > > > Depending on the computer speed and number of extensions, this can take several > seconds. That sounds like an extension doing sync IO or expensive computations when enabled. Saying we shouldn't disable extensions during screen lock so those extensions "only" block during startup isn't a very convincing argument ...
I agree, that's why I wanted to know what kind of extensions he's using.
It would be handy for some extensions like Hamster, Skype, Pomodoro, To Do Lists to have Lock Screen integration - not necessarily indicators, but to show notifications at least. I agree that certain extensions like window-list, alt-tab better be disabled as they would be out of context. Extensions that wish Lock Screen integration should restrict themselves.
> it'll be used to just paper over bugs (from the examples cited above, only the systemMonitor one sounds like a genuine use case). What would be the bug in the App Indicators case?
(In reply to Jan Niklas Hasse from comment #18) > > it'll be used to just paper over bugs (from the examples cited above, only the systemMonitor one sounds like a genuine use case). > > What would be the bug in the App Indicators case? If I recall correctly, the NotifierHost (or what it was called) coming and going is something items have to deal with.
An opt-in would be really nice.
Wouldn't it be better for extensions, which only have indicators, to talk to GNOME Shell via DBus? This could be used to fix this issue and it would make them run in a separate process and might result in performance and stability improvements.
Just as an example, my time++ extension would benefit tremendously from being able to work in the lock screen in some way: https://github.com/zagortenay333/timepp__gnome/issues/5 It's a timer, stopwatch, alarm, pomodoro, and time-tracker, all of which become useless when the user locks the screen. :/
Created attachment 359063 [details] [review] Allow extensions to be shown in the lock-screen If an extension sets 'show-in-lock-screen': true in its metadata.json, it won't get disabled when locking the screen.
With my patch you can add 'show-in-lock-screen': true to your metadata.json which will allow time++ to run even when the screen is locked (opt-out as Florian suggested in #1). Of course the problem is now, that anyone can completely use the extension from the lock-screen and therefore see sensible information (todo tasks). This could be solved by calling Main.panel.statusArea.timepp.actor.hide(). Is there a way to do this automatically?
Well, the extension could decide whether or not to expose sensitive info. I would hide the todo manager, but maybe add an option to expose the timer/stopwatch/pomodoro, for example. By making it possible for the extension to know when it enters the lock-screen, the concerns raised by Florian go away too. If you know you're in the lock screen, don't create modal dialogs.
Can you try if you can do that in your extension? Maybe Main.sessionMode.connect('updated', …) or something like that.
Yeah, you can listen on that signal, but I'm no sure what to do to prevent the extension from being disabled. Either way, it's 'gaming the system' as Florian put it. It has to be explicitly supported by gnome-shell.
I mean listening on that signal in combination with my patch ;)
Review of attachment 359063 [details] [review]: This doesn't work as advertised - the name suggests that the extension is shown on the lock screen, but it's actually shown in *any* mode. Also see https://bugzilla.gnome.org/show_bug.cgi?id=787454#c3 for a more general proposal.
Thanks for the review, it was my first dive into the GNOME Shell code. I thought about that. What other modes are there though? If I understand it correctly extensions aren't loaded in GDM anyway.
(In reply to Jan Niklas Hasse from comment #30) > What other modes are there though? There's no definite answer to that - upstream we have: - user - gdm - lock-screen - unlock-dialog - classic - initial-setup But modes can be defined externally by distros (ubuntu) or system administrators (for example for kiosk systems). > If I understand it correctly extensions aren't loaded in GDM anyway. Yes, but they aren't loaded because GDM's session mode doesn't have the allowExtensions flag set. (Your patch doesn't change that, but see the aforementioned bug for a use case of extensions on the login screen ...)
What do you think about keep-enabled-on-mode-changes for the name of the metadata flag?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.