Some icons disappear when shell is restarted or the session is locked and unlocked

[georgelemental]

Whenever I restart gnome-shell or lock and unlock the session, the KeePassXC and MEGASync indicators disappear. The Dropbox and Safe Eyes indicators do not do this.
I am using Ubuntu 17.04, gnome-shell 3.24, and the latest version of the extension from git.

[tribut]

Seeing the same behavior with nextcloud (Ubuntu 17.04, extension from extensions.gnome.org, nextcloud 2.3.1).

[thermatk]

Same with Telegram Desktop (Qt)
Indicator can be brought back by going to the Settings of the app and disabling and re-enabling "Tray icon"

[jhasse]

I don't think this will be easy to fix without some changes in GNOME Shell itself, see https://bugzilla.gnome.org/show_bug.cgi?id=781760

[JasonLG1979]

To clarify this extension works via the org.kde.StatusNotifierWatcher DBus interface. When the session is locked and then unlocked or GNOME Shell is restarted all extensions are reloaded. So the extension is forced to un-own and then re-own that interface. The apps in question should be listening for that signal but are not apparently?

[jhasse]

Yes, this is how I understand it.

[kwill]

If this can / should be solved in the app, can you provide an info page that we can point app developers to? (And contribute to if it's helpful to add links, say, to libraries and methods in various programming languages / frameworks.)

[jhasse]

If I'm not mistaken this problems only occurs with Qt applications (not with libappindicator). I've created a Qt bug, hopefully it can be fixed upstream: https://bugreports.qt.io/browse/QTBUG-63065

[lestcape]

I really don't see other way to lead with qt app, that reported it.

I think instead of disable the whole extension on a lock screen, is possible check for the session state and base on that just disconnect and connect the signals (hide and show the icons) or really destroy all if the session is not locked. We probably need an AppIndicatorManager to centralized most of this commons actions to be apply to all indicators. Is something similar to this:
https://github.com/linuxmint/Cinnamon/blob/master/js/ui/indicatorManager.js#L104

[JasonLG1979]

Extensions are not given a choice. By GNOME design they are forced disabled.

[lestcape]

Maybe i'm wrong because the extension are a submodule and maybe with some magic it can unloaded complete, but are you not (the developer) who decide what the disable function do?

[jhasse]

Yes, but I don't think there's an easy way to distinguish between a disable request because of a screen lock and a normal disable request.

[lestcape]

When the session is locked, the only way that is possible to me that a user can disable the extension, is if he start another terminal session and use gsettings to disable the extension. I considered this a strange behaviour so not be take in consideration, so with base in this:

The session is synchronized here:
https://github.com/GNOME/gnome-shell/blob/master/js/ui/sessionMode.js#L187

So you can play with Main.sessionMode.isLocked && Main.sessionMode.isGreeter, to detected the lock screen, but also only the extension is removed by the session when the session mode don't allow extensions (https://github.com/GNOME/gnome-shell/blob/033277b68f2910e54ce62f45fa92af2f5092a7ba/js/ui/extensionSystem.js#L361), then, probably it just will work:

var state = null;
function enable() {
      if(state == disconnected) {
           state = connected;
           //Connect and show all.
      } else {
           state = connected;
          //Build, connect and show all.
      }
}

function disable() {
      if(!Main.sessionMode.allowExtensions) {
          state = disconnected;
          //Disconnect and hide all.
      } else {
          state = destroyed;
         //Destroy all.
      }
}

[JasonLG1979]

You really can't get the screen lock signal. Extensions are unloaded before it propagates down the stack. Best you can do is connect to the fade out signal like I do in my other extension.

[lestcape]

This is where the extension will be disable:
https://github.com/GNOME/gnome-shell/blob/033277b68f2910e54ce62f45fa92af2f5092a7ba/js/ui/extensionSystem.js#L361

The function is called because the session mode change first:
https://github.com/GNOME/gnome-shell/blob/033277b68f2910e54ce62f45fa92af2f5092a7ba/js/ui/extensionSystem.js#L366

So, in my opinion you can save used Main.sessionMode.allowExtensions at it represent the current session state, when disable is called.

Note: see i don't capture Main.sessionMode.connect('updated', because yes, in that way this could be like you say. I directly capture the current state of the session, and i'm not capture the lock screen, i'm capture all session modes that cause an upload of the extension, not matter if is because the lock screen or whatever (but really is because the lock screen).

[lestcape]

Demonstration with Reductio ad absurdum (https://en.wikipedia.org/wiki/Reductio_ad_absurdum):

• We supposed that the condition !Main.sessionMode.allowExtensions is incorrect when is capture in the disable function of our extension (absurd). And also we know by experience that the shell code is right.

• Like the disable function of the extension is called by the a session mode change only in this place: https://github.com/GNOME/gnome-shell/blob/033277b68f2910e54ce62f45fa92af2f5092a7ba/js/ui/extensionSystem.js#L361 where the !Main.sessionMode.allowExtensions need to be always true, there are 2 cases:
  1- The shell code is wrong and is called that function incorrect.
  2- The shell code is right.

If the shell code is right, this mean !Main.sessionMode.allowExtensions can not be wrong, because is the only condition that is used in the function _sessionUpdated https://github.com/GNOME/gnome-shell/blob/033277b68f2910e54ce62f45fa92af2f5092a7ba/js/ui/extensionSystem.js#L351 so is enter in contradiction with our hypothesis that was the incorrect condition.

If the shell code is wrong this mean the shell disable the extension when is not correct, but we know that this not occurs and this enter in contradiction with the assumption that the shell code is right.

That's finally prove our theory.

[jhasse]

I don't know if the extension would get through review if it tries to trick the Shell like this. Having support for this upstream would be a cleaner solution, have a look at my patch here: https://bugzilla.gnome.org/show_bug.cgi?id=781760

[lestcape]

@jhasse sorry for my little confidence of the influence of a third-patry extension can do in the gnome upstream. I try to find a solution locally just for my little confidence. In my opinion what you do are correctly and this could save the day, really more easy if will have merged in the upstream, but just if will be merged.

Regards.

[eugene-rom]

This trick works for me with TopIcons Plus to avoid disabling on screen lock - phocean/TopIcons-plus#100 - check "+" marked lines.

[thermatk]

#97 fixed the issue with Telegram and Nextcloud disappearing after suspend on Shell 3.26.1 👍

[jhasse]

If anyone still experiences this with the new version on e.g.o (which includes #97), please comment. Otherwise I think this is fixed with a big thanks to @3v1n0 .