From 4ce0e809562bb10dc092343a926c72c1cf25c0f9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Florian=20M=C3=BCllner?= Date: Tue, 11 Oct 2011 21:53:29 +0200 Subject: [PATCH] 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. https://bugzilla.gnome.org/show_bug.cgi?id=661485 --- js/ui/userMenu.js | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/js/ui/userMenu.js b/js/ui/userMenu.js index 40ca2f39e..311ba73e6 100644 --- a/js/ui/userMenu.js +++ b/js/ui/userMenu.js @@ -285,7 +285,12 @@ IMStatusChooserItem.prototype = { if (presence == Tp.ConnectionPresenceType.AVAILABLE) this._presence.setStatus(GnomeSession.PresenceStatus.AVAILABLE); - if (!this._expectedPresence || presence != this._expectedPresence) + // We ignore the actual value of _expectedPresence and never safe + // the first presence change after an "automatic" change, assuming + // that it is the response to our request; this is to account for + // mission control falling back to "similar" presences if an account + // type does not implement the requested presence. + if (!this._expectedPresence) global.settings.set_int('saved-im-presence', presence); else this._expectedPresence = undefined;