Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ghost opened this issue May 2, 2017 · 48 comments
Assignees
Labels

Comments

@ghost
Copy link

ghost commented May 2, 2017

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
Copy link

tribut commented May 20, 2017

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

@thermatk
Copy link

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
Copy link
Collaborator

jhasse commented May 23, 2017

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

@jhasse jhasse added the bug label May 29, 2017
@JasonLG1979
Copy link
Contributor

JasonLG1979 commented Sep 1, 2017

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
Copy link
Collaborator

jhasse commented Sep 1, 2017

Yes, this is how I understand it.

@lofidevops
Copy link

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
Copy link
Collaborator

jhasse commented Sep 7, 2017

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
Copy link

ghost commented Sep 22, 2017

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
Copy link
Contributor

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

@ghost
Copy link

ghost commented Sep 22, 2017

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
Copy link
Collaborator

jhasse commented Sep 22, 2017

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
Copy link

ghost commented Sep 22, 2017

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
Copy link
Contributor

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
Copy link

ghost commented Sep 22, 2017

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
Copy link

ghost commented Sep 22, 2017

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
Copy link
Collaborator

jhasse commented Sep 22, 2017

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
Copy link

ghost commented Sep 22, 2017

@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
Copy link

thermatk commented Oct 27, 2017

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

@jhasse
Copy link
Collaborator

jhasse commented Nov 1, 2017

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 .

@jhasse jhasse closed this as completed Nov 1, 2017
@ivnilv
Copy link

ivnilv commented Apr 22, 2018

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
Copy link
Contributor

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
Copy link

ghost commented May 4, 2018

@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
Copy link
Contributor

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
Copy link

ghost commented May 4, 2018

@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
Copy link
Contributor

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

@ghost
Copy link

ghost commented May 6, 2018

@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
Copy link
Contributor

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
Copy link

ghost commented May 7, 2018

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

@JasonLG1979
Copy link
Contributor

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
Copy link

ghost commented May 7, 2018

@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
Copy link
Contributor

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
Copy link

ghost commented May 7, 2018

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
Copy link

ghost commented May 25, 2018

@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
Copy link

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
Copy link

NikMel commented Nov 8, 2018

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
Copy link

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

@romansimakov
Copy link

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
Copy link

NikMel commented Nov 13, 2018

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
Copy link

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
Copy link

der-ali commented Feb 1, 2019

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 :/

zhangkaizhao added a commit to zhangkaizhao/gnome-shell-extension-tray-icons that referenced this issue Mar 22, 2019
The disable() of extension is called quickly after session status
changed to idle. We make a mark when we catch this status change
signal and then ignore recreating tray in the following disable(),
and finally reset the mark to avoid normal usage of extension
enable/disable switch.

When session status changed from idle to available, e.g. unlocking
screen, this signal can be caught, but seems there is no easy way to
avoid recreating tray then. Here still does not cover such case when
the user locks the screen manually and then unlocks it.

Inspired by gnome-shell-extensions-morphine [1],
via the long discussion gnome-shell-extension-appindicator #75 [2].
Seems the better way is to connect to DBus but that's too complex.

[1]: https://github.com/JasonLG1979/gnome-shell-extensions-morphine
[2]: ubuntu/gnome-shell-extension-appindicator#75
@lxknvlk
Copy link

lxknvlk commented Nov 20, 2019

Still a problem on Ubuntu 18.04.3 LTS

@spielkind
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests