Bug 38366

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. :(

Here is my not classy but working patch.
http://cgit.collabora.com/git/user/cassidy/telepathy-mission-control/log/?h=offline-38366

Created attachment 48456 [details] [review]
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... :)

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.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-mission-control/issues/42.