Comment 8 for bug 881219

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.