brl/gnome-shell
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

user-menu: Be more cautious about saving status

Browse Source 
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
This commit is contained in:
Florian Müllner 2011-10-11 21:53:29 +02:00
parent 577ccc4d56
commit 4ce0e80956
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
js/ui/userMenu.js
View File

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