GNOME Bugzilla – Bug 658955
i'm not idle
Last modified: 2013-09-06 23:52:45 UTC
Created attachment 196401 [details] screenshot For some reason I am marked as idle. First of all, that is not a good term to use since it is disrespectful. Anyway, I'm not idle. And I have no idea where that setting is coming from.
Mmmh, as I understand it, the idle status should only be set while the screen is locked (at least that is how we interpret telepathy's "extended away" in the user menu). If it worked like that, the user should only ever see the corresponding icon, but not the label - no idea off-hand what is failing for you.
(In reply to comment #1) > the user should only ever see the corresponding icon, but not the label My understanding is that you should be moved to available after coming back to the PC, logging in etc. I see the exact same thing on Fedora 17 / GNOME 3.4, *sometimes*. In other cases it seems to work fine (maybe it is related to timing however), but sometimes the idle status seems to stick and I have to manually set it to available.
I'm reliably getting the same thing on F17.
Just to reiterate the desired behaviour here - the 'busy'/'idle' shouldn't be shown as a string in the user menu. There are two user preferences there - available or unavailable. That's all it should contain. If it's unavoidable that we leak the busy state (I hope it's not), it should be labelled 'Busy' and not 'Idle'.
(In reply to comment #4) > Just to reiterate the desired behaviour here - the 'busy'/'idle' shouldn't be > shown as a string in the user menu. There are two user preferences there - > available or unavailable. That's all it should contain. Are you sure? I think it would be rather confusing that to change from "hidden" to "available", I have to "change" the status in the user menu from "available" to "available" ... > If it's unavoidable that we leak the busy state (I hope it's not), it should be > labelled 'Busy' and not 'Idle'. 'Busy' and 'Idle' are actually different states. You get the former (for instance) by disabling notifications, the latter should only be set while the screen is locked. So in my opinion the bug is that we somehow miss a status change when returning from suspend / the lock screen, not that we show the current status even in cases where it is neither available nor unavailable (of course a workaround could be to just ignore 'idle' altogether, though it means that users will appear online while in reality their screen is locked)
(In reply to comment #5) > (In reply to comment #4) > > Just to reiterate the desired behaviour here - the 'busy'/'idle' shouldn't be > > shown as a string in the user menu. There are two user preferences there - > > available or unavailable. That's all it should contain. > > Are you sure? I guess not. > I think it would be rather confusing that to change from "hidden" > to "available", I have to "change" the status in the user menu from "available" to "available" ... Hadn't realised we update this according to what we set in Empathy. But why have the label as 'Hidden' and not 'Invisible'? > > If it's unavoidable that we leak the busy state (I hope it's not), it should be > > labelled 'Busy' and not 'Idle'. > > 'Busy' and 'Idle' are actually different states. You get the former (for > instance) by disabling notifications, the latter should only be set while the > screen is locked. I think it's important that the combobox reflects the exposed state. When I lock my screen, it should switch my public status to Away, and the combobox should reflect that (see bug 676109). > So in my opinion the bug is that we somehow miss a status > change when returning from suspend / the lock screen, not that we show the > current status even in cases where it is neither available nor unavailable (of > course a workaround could be to just ignore 'idle' altogether, though it means > that users will appear online while in reality their screen is locked) OK.
(In reply to comment #6) > > I think it would be rather confusing that to change from "hidden" > > to "available", I have to "change" the status in the user menu from "available" to "available" ... > > Hadn't realised we update this according to what we set in Empathy. But why > have the label as 'Hidden' and not 'Invisible'? Gah, really only because the telepathy API uses "hidden". I just checked, and Empathy indeed renamed the status to "Invisible" in early 2010 (see bug 603472) ... > I think it's important that the combobox reflects the exposed state. When I > lock my screen, it should switch my public status to Away, and the combobox > should reflect that (see bug 676109). Yeah, that's how it is supposed to work, but it's obviously buggy :-( I can't reproduce the issue reliably, but I might have an idea what's causing it - I'll try to look into it.
Created attachment 217019 [details] [review] userMenu: Rename 'Hidden' to 'Invisible' Apparently only the Telepathy API calls this status 'Hidden', Empathy and most network use 'Invisible' (also see https://bugzilla.gnome.org/show_bug.cgi?id=603472).
Comment on attachment 217019 [details] [review] userMenu: Rename 'Hidden' to 'Invisible' Attachment 217019 [details] pushed as 01c07fb - userMenu: Rename 'Hidden' to 'Invisible' (patch doesn't need review, I was attaching it basically for the bug reference)
After the patch, whats left to do here ?
The patch just fixed a string inconsistency that came up in the comments, not the actual bug.
So, what is the fix for the actual bug ?
This very well could be an X server bug: http://lists.x.org/archives/xorg-devel/2012-July/032911.html
Any updates on this? I'm still seeing the bug in GNOME 3.6, including the "Idle" string.
*** Bug 683243 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > Any updates on this? I'm still seeing the bug in GNOME 3.6, including the > "Idle" string. Confirmed, gnome-shell 3.6.2 is still affected.
I can reproduce this 100% after each resume from suspend state on 3.6.x - is anyone working on this so it can be fixed in 3.8.0 at last?
I can also reproduce this after resuming from suspend. There is also another way to reproduce it: 1) Open lock screen 2) Make the network go down (e.g. by unplugging the network cable) 3) Reconnect the network 4) Unlock the screen I think the reason why this bug happens is because gnome shell is setting the IM status to extended away on step 1). Then telepathy is setting it to offline in step 2). On step 3) when the network connection is restored it resets "extended away" which was the previous state. This is detected by gnome shell which stores the state in "saved-im-presence" (in userMenu.js). When the screen is unlocked on step 4) it won't change the state back to available as the value of "saved-im-presence" is the "extended away" state.
This is happening as well for me on 3.8, with similar ways to reproduce as described in comment #17 and comment #18. What makes this bug worse IMO is the idle state also persists after a reboot. Since "Idle" is not a state you can explicitly set from the user menu, I think we should at least make sure we're not restoring it at startup.
(In reply to comment #19) > Since "Idle" is not a state you can explicitly set from the user menu, I think > we should at least make sure we're not restoring it at startup. The current behavior is to save/restore any presence that we didn't set ourselves, not just those set from the combo box (e.g. including presence changes triggered by setting the state from empathy, which includes "Idle"). I don't like the idea of special-casing "Idle" here, but I'm open to tying save/restore to presence set by the combo box - Allan? In any case, I'll attach a cleaned up patch later today which seems to fix the idle-after-suspend issue for me ...
(In reply to comment #20) > The current behavior is to save/restore any presence that we didn't set > ourselves, not just those set from the combo box (e.g. including presence > changes triggered by setting the state from empathy, which includes "Idle"). I > don't like the idea of special-casing "Idle" here, but I'm open to tying > save/restore to presence set by the combo box - Allan? I agree special-casing doesn't seem the best solution, but you're saying automatic states should escape the save/restore mechanism here, so probably it's just a bug then? I'll wait for your patch :)
I think it makes sense to only save/restore presences that the user explicitly sets.
Created attachment 238889 [details] [review] userMenu: Set presence to "extended away" before suspending We currently rely on GnomeSession's presence status to set the online presence to "extended away". In case we are suspending, this means that the machine might go to sleep before the presence has actually been updated, resulting in the status being stuck to "idle" after resuming - either because we set the status ourselves when coming back, or because we pick up a presence change initiated by the server side after a timeout. To fix this, handle the suspend case explicitly using logind's inhibit() API.
Why can't gnome-session use logind's inhibit() API itself?
(In reply to comment #22) > I think it makes sense to only save/restore presences that the user explicitly > sets. Changing the presence in empathy is an explicit user action :-) However as mentioned in comment #20, I'd be OK with limiting state saving to the combo box (if the designers agree), but it's rather intrusive, so I'd prefer leaving it for 3.10 in any case.
(In reply to comment #24) > Why can't gnome-session use logind's inhibit() API itself? Because gnome-session doesn't deal with telepathy presence at all. So unless we move this part into gnome-session (which is obviously out of question for 3.8), all it can do is ensuring that org.gnome.SessionManager.Presence is set to IDLE before suspending, which means we can still end up suspending before setting the telepathy presence.
I guess the main problem here is that at least one Telepathy client in the system sets presence in response to system events, but the save/restore logic does not have visibility on why the other setters have changed it, so it assumes any externally changed status comes from the user and should be preserved. Note also that the Telepathy account property RequestedPresence should not be persisted, as it is meant precisely for such "situational" changes. There is another property, AutomaticPresence, suitable for persisting.
(In reply to comment #27) > Note also that the Telepathy account property RequestedPresence should not be > persisted, as it is meant precisely for such "situational" changes. Didn't you get that backwards? We want to persist presence changes initiated by the user, not changes that are done automatically - so I guess something like "RequestedPresence unless triggered by a change of AutomaticPresence" (ugh, should be fun to implement ...)
(In reply to comment #28) > Didn't you get that backwards? We want to persist presence changes initiated by > the user, not changes that are done automatically - so I guess something like > "RequestedPresence unless triggered by a change of AutomaticPresence" (ugh, > should be fun to implement ...) Don't get confused by the name. The specification makes this clear: http://telepathy.freedesktop.org/spec/Account.html#Property:RequestedPresence Basically, the meaning is as follows: AutomaticPresence - the "ideal" presence, reached unless system conditions prevent it. This is where the user's preference should go. RequestedPresence - the currently requested presence, affected by prevailing temporary conditions in the system. CurrentPresence - a read-only value of the actual presence. IIRC the naming caused some anguish when the spec was drafted...
(In reply to comment #29) > AutomaticPresence - the "ideal" presence, reached unless system conditions > prevent it. This is where the user's preference should go. Yes. Whenever we want to "go online, somehow" (for instance because you try to call or chat to someone while offline - MC and Telepathy fully support this, even if Empathy doesn't), it's implemented as "copy AutomaticPresence into RequestedPresence". Because of that use, AutomaticPresence is never offline: it's always one of the online statuses (available, away, busy, etc.). If you want to save "this account is/isn't normally online" it's possible to combine AutomaticPresence with ConnectAutomatically, though. See also <https://bugs.freedesktop.org/show_bug.cgi?id=24104#c2> which proposes some additional "shortcut" APIs on the AccountManager.
(In reply to comment #23) > userMenu: Set presence to "extended away" before suspending If anything, don't you want to go completely offline before suspending? Your IM connections aren't going to keep working across a suspend anyway, unless you happen to resume within one TCP timeout period and get the same IP address.
Created attachment 239003 [details] [review] userMenu: Set presence to "offline" before suspending (In reply to comment #29) > Don't get confused by the name. The specification makes this clear: > > http://telepathy.freedesktop.org/spec/Account.html#Property:RequestedPresence > > Basically, the meaning is as follows: > > AutomaticPresence - the "ideal" presence, reached unless system conditions > prevent it. This is where the user's preference should go. Mmh yes, the name is utterly confusing :-) (In reply to comment #30) > Yes. Whenever we want to "go online, somehow" (for instance because you try to > call or chat to someone while offline - MC and Telepathy fully support this, > even if Empathy doesn't), it's implemented as "copy AutomaticPresence into > RequestedPresence". But is that what we want? We do want to restore the actual presence, e.g. the user's visibility to the outside world, not some "default" that should be switched to once the user initiates some communication. If we do change the behavior to only save/restore the presence as set in the shell itself, we will basically end up storing a simple boolean (connect-on-startup - is that what ConnectAutomatically would give us, so we could just stop saving any presence and just the property any time users change their online status?) I'm probably still confused ... In any case, can you file a separate bug for this? I don't really see it related to this bug, and I don't see it as a 3.8 blocker either (not to mention that it's probably a fairly intrusive change which I'm not confident with three days before RC) (In reply to comment #31) > (In reply to comment #23) > > userMenu: Set presence to "extended away" before suspending > > If anything, don't you want to go completely offline before suspending? Makes sense, updated patch.
Any review here ?
sad that we didn't get this in, but it is not really something we should block on.
Can we get this in for 3.8.1?
The IM presence is no longer settable from the shell (either explicitly by the user or automatically in response to some event), so this is obsolete now.