After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 661485 - Does not restore IM status when unlocking the screen
Does not restore IM status when unlocking the screen
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: telepathy
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME Shell Telepathy maintainer(s)
gnome-shell-maint
: 661420 662008 670027 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-10-11 19:14 UTC by Guillaume Desmottes
Modified: 2013-11-01 08:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
user-menu: Be more cautious about saving status (1.87 KB, patch)
2011-10-11 20:11 UTC, Florian Müllner
committed Details | Review

Description Guillaume Desmottes 2011-10-11 19:14:47 UTC
gnome-shell master.

- Be sure your IM status is available
- Lock your screen
- Your status is changed to Away
- Unlock your screen
- Your status is still Away
Comment 1 Guillaume Desmottes 2011-10-11 19:44:08 UTC
To trigger this bug you need a Salut account connected. As it doesn't implement extended away, mission-control fallbacks to away (which is fine), resulting in the Shell saving Away as status in gsettings.

So when unlocking it restores the presence to away.
Comment 2 Florian Müllner 2011-10-11 20:11:25 UTC
Created attachment 198809 [details] [review]
user-menu: Be more cautious about saving status

When requesting a presence change, the actual presence set by
mission control does not necessarily match the requested presence
(if an active account does not support the requested presence),
which may result in the wrong presence being restored.
As a fix, be more cautious about saving status by assuming that
users do not request presence changes between an automatic presence
change request and the actual change.

(I'm not completely happy with that change, as the aforementioned assumption may very well be wrong when on an extremely bad network (desktop summit *cough,cough*) - maybe using a condition like (!this._expectedPresence || presence < this._expectedPresence) makes sense?)
Comment 3 Guillaume Desmottes 2011-10-13 17:40:29 UTC
*** Bug 661420 has been marked as a duplicate of this bug. ***
Comment 4 drago01 2011-10-17 21:04:03 UTC
Review of attachment 198809 [details] [review]:

Looks like it should work (I assume you have tested it), so good to go I guess.
Not sure we need the log() though ... it might help debugging corner cases but otoh it may result into bug reports due to the "error message".
Comment 5 Florian Müllner 2011-10-17 21:53:29 UTC
(In reply to comment #4)
> Looks like it should work (I assume you have tested it), so good to go I guess.

I did, but with a limited amount of tp accounts and only on my network (not exactly fiber, but not a super-slow conference network either ...)


> Not sure we need the log() though ... it might help debugging corner cases but
> otoh it may result into bug reports due to the "error message".

Mmmh, I'd prefer leaving it there for now - in case there are corner cases where the fix fails, the message should be helpful. On the other hand, while it works as expected I wouldn't really expect it to show up in bug reports ...
Comment 6 Cosimo Cecchi 2011-10-18 02:06:53 UTC
*** Bug 662008 has been marked as a duplicate of this bug. ***
Comment 7 Florian Müllner 2011-10-18 02:33:01 UTC
Attachment 198809 [details] pushed as 4ce0e80 - user-menu: Be more cautious about saving status

Owen agreed with the "log spam" comment, so I changed the log() to a comment instead.
Comment 8 Julien Olivier 2012-01-19 22:03:27 UTC
I have just upgraded to Ubuntu Precise Pangolin, which provide gnome-shell v3.2.1, and now the bug is back. I don't know if it's an Ubuntu-specific bug though...
Comment 9 Julien Olivier 2012-01-20 15:42:12 UTC
My bad, it still works. It just takes about 30 seconds to reconnect.
Comment 10 Guillaume Desmottes 2012-02-14 08:05:16 UTC
*** Bug 670027 has been marked as a duplicate of this bug. ***
Comment 11 George Kiagiadakis 2013-11-01 08:24:28 UTC
I can reproduce this bug in gnome 3.8... With a salut account enabled, it's always reproducible. The global status always remains "away" or "xa" after unlocking the screen. Without it enabled, it happens to work sometimes, but still this morning after coming out of suspend I noticed my status was "Idle" (?!), which in fact meant xa for all accounts except my voip one...