Empathy switches from "invisible" to "away" when monitor goes into power-saving mode or screen is locked

Bug #881219 reported by T Martin on 2011-10-25
50
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Empathy
Confirmed
Medium
empathy (Ubuntu)
Medium
Unassigned

Bug Description

When using gtalk if you are invisible, the screensaver / monitor off should not switch you to visible / away. You should remain invisible.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: empathy 3.2.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic x86_64
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
Date: Tue Oct 25 00:00:10 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20110901)
SourcePackage: empathy
UpgradeStatus: No upgrade log present (probably fresh install)

As discussed [1] during the IM hackfest, Busy may not be the best fallback if invisible/hidden is not implemented. It should fallback to offline instead so a "Online / Invisible" switch is enough to easily control our visibility on IM.

[1] https://live.gnome.org/Hackfests/IMContacts%20Social2011/Tasks/ShellDesignPresence

Do you really want that? If I go invisible I still want to receive messages and be able to write to people, but if mc silently puts me offline I cannot do it anymore.

This will just be with accounts not supporting invisible:
- link-local
- Facebook
- IRC
- Some shitty XMPP servers

The right fallback from invisible is somewhat situational.

When you set your RequestedPresence to invisible, I think offline is probably the right fallback; you wanted to be invisible and are willing to sacrifice some connectivity to get it.

If your AutomaticPresence is invisible and you're connecting in order to request a channel, the fallback needs to be Busy or Away: whenever you go online with automatic presence, the important thing is that you're online, and the fact that it's with automatic presence is secondary.

The other thing that AutomaticPresence does is that it's what is requested if ConnectAutomatically is true and connectivity becomes available, but because we don't have useful connectivity plugins yet (see Bug #24762), that's not directly relevant right now. For the "eagerly go online when NetworkManager says we can" use-case, I think offline is the right fallback if invisibility is impossible.

Complicating this is the fact that on XMPP, we can't tell whether we're going to be able to be invisible til halfway through connecting. Gabble should grow some way to distinguish between "invisible if possible" and "invisible and I really mean it" - Gabble can do the latter reliably (even though MC can't), by disconnecting before sending initial presence if it looks as though invisibility isn't going to work.

However, it needs to know whether to do that - for the "about to request a channel" case, that'd be counter-productive. Perhaps MC could temporarily insert {"online-even-if-visible": TRUE} into the Parameters, if supported by the CM, when putting an account online for a channel request?

For bonus points, every time we go online MC could remember whether invisibility works, so we can just stay offline next time we want to be invisible.

(In reply to comment #3)
> whenever you go
> online with automatic presence, the important thing is that you're online

This is not true, as demonstrated by the paragraph that followed it. What I really meant is "whenever you go online to request a channel".

Some plausible use cases for being genuinely offline as far as IM is concerned:

* I really, really don't want to be disturbed (but still need a web browser)

* I'm on a sufficiently flaky network connection that if you send me a message
  there's a good chance it'll just get lost (most IM protocols don't have
  application-level acks, so there's a ~30 second window of message loss
  every time you drop off the overloaded conference wifi)

* Using a particular network connection for some/all IM protocols is expensive
  (either in terms of money or battery capacity - 3G can be both!)

(In reply to comment #3)
> If your AutomaticPresence is invisible and you're connecting in order to
> request a channel, the fallback needs to be Busy or Away: whenever you go
> online with automatic presence, the important thing is that you're online, and
> the fact that it's with automatic presence is secondary.

Is there any client actually using that feature?

Humm falling back to Offline instead of Busy is actually more complicated that I would have hoped.
Not being able to call SetPresence('offline') introduces asymetry in the code. :(

Created attachment 48456
Fallback to Offline instead of Busy if Hidden is not supported (#38366)

That makes more sense as if you really want to be invisible you should be
ready to sacrifice some connectivity to get it.

(In reply to comment #6)
> (In reply to comment #3)
> > If your AutomaticPresence is invisible and you're connecting in order to
> > request a channel
>
> Is there any client actually using that feature?

I think it's the right thing for collaborative applications: if I say "share this document" in AbiWord, it should be able to offer me an account chooser and fire off a TpAccountChannelRequest with no further MC interaction, even if I'm not currently online. But if you think this feature is useless, I'd still like a regression test that demonstrates that MC does something vaguely sensible instead of crashing (i.e. the channel request fails, probably).

Regression tests that this feature should have include:

* be online, go invisible (via RequestedPresence), connection doesn't
  support it, fall back to disconnecting

* be offline, AutomaticPresence = invisible, go online for a channel request,
  connection doesn't support it, either Disconnect() is called without calling
  Connect (request fails gracefully [1]) or the fallback is to busy

* be offline, go invisible (via RequestedPresence), connection doesn't
  support it [2], Disconnect() is called without first calling Connect()

[1] We'd probably need a new error, WouldBreakInvisibility? Or you could
    remove the feature entirely and only allow channel requests on online
    accounts, but that would make me very sad.

[2] This won't do what you hope it does - Gabble can't announce definite
    support for invisibility until it has nearly finished connecting.
    So we probably need Gabble changes, to make it always allow
    setting invisible presence before going online, then if it discovers
    lack of invisibility support, disconnect with WouldBreakInvisibility
    instead of sending initial presence.

(In reply to comment #10)
> (In reply to comment #6)
> > (In reply to comment #3)
> > > If your AutomaticPresence is invisible and you're connecting in order to
> > > request a channel
> >
> > Is there any client actually using that feature?
>
> I think it's the right thing for collaborative applications: if I say "share
> this document" in AbiWord, it should be able to offer me an account chooser and
> fire off a TpAccountChannelRequest with no further MC interaction, even if I'm
> not currently online.

Account chooser? Surely a contact chooser. And to show a contact chooser with relevant contacts in it, it needs to be online for caps... :)

T Martin (mortramalt) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in empathy (Ubuntu):
status: New → Confirmed

I'm seeing the same thing on 11.10 with AOL instant messenger.

Bilal Shahid (s9iper1) wrote :

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at:https://bugzilla.gnome.org/show_bug.cgi?id=666287

Changed in empathy (Ubuntu):
status: Confirmed → Incomplete
status: Incomplete → Confirmed
Changed in empathy:
importance: Unknown → Medium
status: Unknown → New
Changed in empathy:
status: New → Confirmed
Omer Akram (om26er) on 2012-01-02
Changed in empathy (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged

http://cgit.collabora.com/git/user/cassidy/telepathy-mission-control/log/?h=offline-38366 now contains tests (covering the 3 scenarios you described) and a couple of fixes.

I didn't add a new error as that will require changing the spec first but can easily do it once we agree that's the right approach.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.