After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 550502 - Invisible Status Is Not Working Correctly
Invisible Status Is Not Working Correctly
Status: RESOLVED OBSOLETE
Product: empathy
Classification: Core
Component: General
2.28.x
Other Linux
: Normal normal
: ---
Assigned To: empathy-maint
empathy-maint
: 609920 639509 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-09-02 15:50 UTC by Joe
Modified: 2018-05-22 13:14 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28



Description Joe 2008-09-02 15:50:20 UTC
The invisible status ("hidden") is not working correctly when connecting to AIM and Yahoo via Haze.  Instead of being invisible, the user shows up visible but with a status of "busy."  I'm not sure why this is since it works correctly on other instant messaging clients that use libpurple.
Comment 1 Guillaume Desmottes 2009-01-18 20:08:45 UTC
Will: Is that a known Haze bug?
Comment 2 Will Thompson 2009-02-02 08:49:14 UTC
No, it's not. Haze purports to support being invisible on AIM, but indeed picking it in Empathy doesn't seem to do the right thing. I just played a bit with telepathy-inspector and crashed Haze. :-) Actually, calling SetStatus({'invisible':{}}) with d-feet did the right thing, so this smells like an Empathy bug.

Empathy sets the presence via mission control, right? Turns out that aim.profile doesn't list invisible as a SupportedPresence, so I guess Empathy never actually tries to set it.

So this an MC or Empathy bug.
Comment 3 Sumana Harihareswara 2009-10-24 23:55:25 UTC
Still happening -- tested on Empathy 2.27.92 on Jaunty.  I had another user on my contact list use Empathy to log into his AIM account and mark himself Hidden.  I still saw him (marked as Away).
Comment 4 Sumana Harihareswara 2009-10-24 23:59:43 UTC
Additional note: the person who marked himself Invisible was running Empathy 2.28.0.1 on Karmic.  So actually this bug is still happening in 2.28.x.
Comment 5 Ben Thornton 2010-04-09 23:10:44 UTC
I've just begun using Ubuntu 10.04 (Lucid Lynx) Beta 2 with Empathy 2.30.0.  When I added my AIM account, I was able to successfully change my status to "Invisible", however I was not able to when I added my Google Talk account.  Furthermore, when I logged into Gmail in my browser, the chat widget reported that I was logged in from a client that does not support "Invisible" status.
Comment 6 Juanma 2010-07-14 13:12:46 UTC
On Ubuntu 10.04 the invisible mode with a MSN account doesn't work. After a while, Empathy set my status to busy. It's very annoying.
Comment 7 Danielle Madeley 2010-10-01 02:46:59 UTC
(In reply to comment #6)
> On Ubuntu 10.04 the invisible mode with a MSN account doesn't work. After a
> while, Empathy set my status to busy. It's very annoying.

This bit is specifically bug #609920 and probably unrelated to MSN.
Comment 8 Danielle Madeley 2010-10-01 03:52:26 UTC
Ok, so having a look at this. It seems that the immediate problem is when a CM doesn't support invisible and instead picks up some other status (e.g. 'dnd', as happens with salut; or gabble for GTalk [??]). Thus when TpAccountManager calculates the new most-available-presence it's 'dnd', so the status chooser, which is simply wired up to ::most-available-presence-changed, changes to 'dnd'.

If you only have Connections supporting 'hidden', the status stays at 'hidden' like you'd expect.

It's not obvious what to do here, I suppose the presence chooser needs some indication that different CMs have adopted different presences (this is a more generic problem). Furthermore, we should probably indicate when a given status isn't available for all Connections somehow.
Comment 9 Danielle Madeley 2010-10-01 03:59:00 UTC
     Account: gabble/jabber/danielle_2emadeley_40collabora_2eco_2euk0
     Current: hidden (5) ""
   Requested: hidden (5) ""

     Account: salut/local_xmpp/account0
     Current: dnd (6) ""
   Requested: hidden (5) ""

One solution would be to show "most available requested presence" with some sort of marker to indicate that "most available current presence" is not the same value.
Comment 10 Guillaume Desmottes 2010-10-01 08:13:25 UTC
(In reply to comment #9)
> One solution would be to show "most available requested presence" with some
> sort of marker to indicate that "most available current presence" is not the
> same value.

Agreed. We could have the "warning" icon in the presence chooser and hoovering on it would display a tooltip explaining that some accounts have a different presence.
Comment 11 Danielle Madeley 2010-10-07 22:19:08 UTC
*** Bug 609920 has been marked as a duplicate of this bug. ***
Comment 12 Danielle Madeley 2010-10-11 08:25:15 UTC
https://bugs.freedesktop.org/show_bug.cgi?id=30765 is the tp-glib bug to add most-available-requested-presence to TpAccountManager.
Comment 13 Guillaume Desmottes 2011-01-17 08:31:06 UTC
*** Bug 639509 has been marked as a duplicate of this bug. ***
Comment 14 Mehmet Giritli 2012-09-12 09:24:21 UTC
Is this actually two bug reports in one?

First we have the haze problem (or empathy problem on haze) as mentioned in comment 2, and then we have the multiple accounts having different statuses problem.

I am actually here for the unavailability of the invisible status for MSN account via haze. AFAIK pidgin and thus haze supports this since a long time...
Comment 15 Carlos Manso 2013-02-08 15:46:04 UTC
I don't know why this bug in MSN is still active. MSN should support it since pidgin can do that. But if's impossible to do at least there should be a message telling that some account doesn't support invisible, or remove it from the choosing.
Comment 16 GNOME Infrastructure Team 2018-05-22 13:14:17 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME'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.gnome.org/GNOME/empathy/issues/26.