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

[ghost]

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.

[lofidevops]

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

[ghost]

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.

[ghost]

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.

[ghost]

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.

[ghost]

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).

[ghost]

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

[ghost]

@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.

[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 .

[ivnilv]

Still happening on:

$ gnome-shell --version
GNOME Shell 3.28.1

If I do ALT+F2; type "r" , app icons (such as slack, skype, etc.) reappear back on the top bar.

However, if I lock my desktop for a second, and the log back in - icons are gone ??

[JasonLG1979]

Letting extensions on the lock screen would turn into a "Me Too" party. Pretty soon every extension would find it's way to the lock screen,lol!!! Although I don't see the harm in letting them continue to run in the background? Just make them invisible and non-interactable? At least allow them to save their pre-lock state? Which if you REALLY wanted to you could do with gsettings btw... Just save a json as a string and parse it latter.

[ghost]

@JasonLG1979 there are a signal that is emitted when a session change, but is the shell connected at the first client to this signal and when a signal is emitted the first shell steep is disable (finalized) all extensions. So, you need in the middle of you finalized processes save the data and then finalized the extension. There are not such thing like a pre-lock state.

Anyway, i think is better just keep update your file and when the time to died come, you can die in peace and tranquility, because your legacy is saved in advance.

[JasonLG1979]

You can detect when the shell Might be about to lock.
https://github.com/JasonLG1979/gnome-shell-extensions-morphine/blob/master/src/extension.js#L154-L162

It's a matter of if you'd have time to save anything?

[ghost]

@JasonLG1979 Yes, is a matter of time only. The shell is also connected to the same signal and his handler is called first than your handler (the extension handler).

[JasonLG1979]

Just Monkey Patch that handler then? I'm not sure they'd allow that though?

[ghost]

@JasonLG1979 I don' t know...

The workaround of store the dbus properties is working in the global menu. So, i don' t lost any Dbus connection from Qt anymore: https://github.com/lestcape/Gnome-Global-AppMenu/commit/1a6a9711d88f798612c75263438389d9c246e218

[JasonLG1979]

That might work. Just keep a running list of the interfaces as they appear and disappear and then when the extension is enabled check to see if those bus names are still owned. If they are, reconnect to them if not take them off the list?

[ghost]

I keep the list update, the only problem i found is this: https://gitlab.gnome.org/GNOME/gnome-shell/issues/257

[JasonLG1979]

I keep the list update, the only problem i found is this: https://gitlab.gnome.org/GNOME/gnome-shell/issues/257

Assuming the indicators interfaces survive a Shell restart/lock/login - logout it shouldn't matter. You shouldn't need to know why the extension restarted. In this case you should be able to just check to see if the interfaces in the list are still owned. If they are (in the case of a restart/lock - unlock) use them, if not (in the case of a logout/reboot) throw them away, remove them from the list and move on. Worst case you have a stale list.

[ghost]

@JasonLG1979 i'm not working with StatusNotifierItem (https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNotifierItem/). I'm working with the com.canonical.AppMenu.Registrar This is a different iface. Is one that need the xid of the window. So, i need a close relation between the window and his interface. That is the difference and is why i need both things: the windows list and the interface on dbus. I ending up, following the interface and not the windows list and with that, i resolve the problem. Just i ending watching all interfaces that call the registrar. This is for all menus that i found his interface:

let nameWatcherId = Gio.DBus.session.watch_name(
          senderDbus, Gio.BusNameWatcherFlags.NONE,
          Lang.bind(this, this._busNameAppeared, xid),
          Lang.bind(this, this._busNameVanished, xid)
);

Then when the interface appeared and i have the window in the tracker windows list with the xid that was called the registrar, I add this dbus properties to my list and when the dbus interface is vanished I remove the dbus properties from my list in this case without take in consideration the windows tracker, because the windows tracker clean his list in a restart.

[JasonLG1979]

I'm working with the com.canonical.AppMenu.Registrar This is a different iface.

This may be related but this specific bug has to do with StatusNotifierItem and gnome-shell-extension-appindicator. That is why I said "in this case". I am talking about the bug in this report.

[ghost]

Yes, is the same bug, cause by the same toolkit (qt) and from the same distro (ubuntu), but with a different Dbus iface. This is why i shared my experience here. With StatusNotifierItem, is really several time more easy, just you need to watch the dbus iface. So, it will work without a problem.

[ghost]

@jhasse if you are waiting for a decision of your pull. I think you need to see this thread: https://gitlab.gnome.org/GNOME/gnome-shell/issues/237

[abePdIta]

Still happening on:

$ gnome-shell --version
GNOME Shell 3.28.1

If I do ALT+F2; type "r" , app icons (such as slack, skype, etc.) reappear back on the top bar.

However, if I lock my desktop for a second, and the log back in - icons are gone ??

Exactly the same. GNOME Shell 3.28.3 on Ubuntu 18.04.1 upgraded from 16.04.

[NikMel]

Seeing the exact same behaviour on Ubuntu 18.10 with gnome-shell version 3.30.1.

I've also tried disabling all extensions (just to verify that it wasn't just one extension that somehow was misbehaving), but the problem persists.

Just found this: https://askubuntu.com/a/968305
It seems that indicator-application (the indicator icon tray functionality from unity, I thing) is messing with gnome-shell. I had it installed for some reason, and after removing it my icons stay after locking and unlocking.

/Niklas

[iljapelech]

Can confirm what @NikMel says. Had the same problem solved by removing indicator-application.

[romansimakov]

I'm afraid you are wrong. I had an original problem on 18.04. In that case tray icons disappeared every time when I locked screen. Now in Ubuntu 18.10 it happend sometime. I have no idea when exactly. Restart of gnome-shell via killall -HUP gnome-shell helps to return normal tray and keep applications running.
indicator-applications does not affect. I removed it and now see the same problem. My friend have clean installation of Ubuntu 18.10 without indicator-application at all.
Maybe it's possible to enable more detailed logging in gnome-shell. I'd try to collect more data but how?

[NikMel]

I'm afraid you are wrong. I had an original problem on 18.04. In that case tray icons disappeared every time when I locked screen. Now in Ubuntu 18.10 it happend sometime. I have no idea when exactly. Restart of gnome-shell via killall -HUP gnome-shell helps to return normal tray and keep applications running.
indicator-applications does not affect. I removed it and now see the same problem. My friend have clean installation of Ubuntu 18.10 without indicator-application at all.
Maybe it's possible to enable more detailed logging in gnome-shell. I'd try to collect more data but how?

Well, I/we aren't necessarily wrong, as your issue might have a different cause than ours. After my previous post (now three days ago) I haven't had a single problem, so...

But, did you try to disable all other extensions to verify that it isn't something else that is causing your issue?
Gnome-shell's way of dealing with extensions is a bit, well, strange... A misbehaving extension can easily bring the whole shell down with it (which may manifest exactly as you describe).

You can get the gnome-shell logs by running:
journalctl /usr/bin/gnome-shell

or get continous logging by running (start this before suspending/locking, and then check the output after resuming):
journalctl -f /usr/bin/gnome-shell

[DmitryMelnyk]

I had the same problem with disappearing icons after lock screen on my Ubuntu 18.10 GNOME Shell 3.30.1

Removing default [email protected] from /usr/share/gnome-shell/extensions and installing this extension fixed problem for me.

[der-ali]

i have the same problem on ubuntu 18.04 with GNOME Shell 3.28.3. I need each time to do ALT+F2; type "r" to get them back :/

[lxknvlk]

Still a problem on Ubuntu 18.04.3 LTS

[spielkind]

Seems that the problem reoccurred with (electron8 electron/electron#22443)
Tried with hamsket nightly (electron 8.1.x) & kebyase 5.3.0 (electron 8.x.x).

Reloading shell with ALT-F2+'r' doesn't fix it on contrary, the icons will disappear.
May an electron issue? Not sure.