Bug 111537 - jabber contact should not log off then log back in when resource changes
Summary: jabber contact should not log off then log back in when resource changes
Status: RESOLVED FIXED
Alias: None
Product: kopete
Classification: Applications
Component: Jabber Plugin (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR critical
Target Milestone: ---
Assignee: Kopete Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-26 09:46 UTC by Vincent P
Modified: 2009-06-25 19:13 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent P 2005-08-26 09:46:55 UTC
Version:            (using KDE KDE 3.3.2)
Installed from:    Debian testing/unstable Packages
OS:                Linux

Login in to google talk with jabber plugin of kopete works allright.
Adding a Google talk contact works fine.
When talking to a GG talk contact, kopete seems to think this contact logged off and in every time he types something. The consequence is a logoff-login animation in contact list for this user, and a new tab opened every time this contact send an IM. The latter is very annoying to follow a conversation.
It seems that Google Talk users randomly change their jabber resource to something like user@gmail.com/talk.<random_string> , <random_string> beeing a string of random characters. This makes kopete think the GG talk user logged off and in.
Comment 1 Vincent P 2005-08-26 12:30:43 UTC
Problem submitted to Google Talk as well. Awaiting answer...
Comment 2 Arend van Beelen jr. 2005-08-26 15:51:09 UTC
I can confirm this behaviour with a self-compiled Kopete 0.10.3 on SUSE 9.3. However, apparently it's not Kopete that _thinks_ the user logged off and on, the other user actually does log off and on. This logging off seems to be triggered the moment you start typing something to the other contact.
Somehow it seems the notification Kopete sends which is responsible for the "Joe is typing a message..." in the statusbar is confusing the Google Talk client.

Please note that when you get a new tab for an IM of that user, then continueing to type in the old tab does not disconnect the other client, whereas he will still receive your message. Just as soon as you start typing in the _new_ tab, the other user will disconnect.
Comment 3 Raymond Lewis Rebbeck 2005-08-28 00:35:15 UTC
I can also confirm this behavour on Gentoo Linux with Kopete 0.10.2

Attempting to talk to users who use the official Google talk client results in them being disconnected. It does appear to be a problem with the typing notification as they are often disconnected merely by typing to them. Afterwards the effect seems to be somewhat sporadic with messages randomly getting through as the user is randomly disconnected as you further attempt to talk to them.
Comment 4 Matt Rogers 2005-08-31 23:00:08 UTC
this needs to be fixed before KDE 3.5
Comment 5 Arend van Beelen jr. 2005-08-31 23:07:57 UTC
That would be very nice yes, but unfortunately we don't have very much influence on it as it appears to be a bug in Google's client. It's their client that logs off and on when it receives a typing notification from Kopete.
What I could suggest though, is that we add a hack to simply disable these notifications when chatting with @gmail.com accounts on Jabber. Probably there would be no problem anymore, there's no lost functionality (as Google's client doesn't support the notifications anyway) and everyone's happy. It can then always be enabled again when Google's client can handle it...
Comment 6 Raymond Lewis Rebbeck 2005-08-31 23:14:39 UTC
As far as I know this problem does not exist in other clients, such as gaim or ichat. What are they doing differently that doesn't cause this problem?
Comment 7 Olivier Goffart 2005-08-31 23:55:04 UTC
AFAIK, the JEP 22 specify that a contact has to ask for notification event in order to receive it.

Kopete does sent theses event even if they are not asked (i'm not sure about that)  because of a lack in libiris
By reading the JEP22 , i don't know if it's against the XMPP protocol to do that,  conform client implementation should ignore unknown tag (i think)

But there was an issue with the Gajim client which shown empty messages. Or some web java client)
Comment 8 Olivier Goffart 2005-09-01 00:39:43 UTC
the problem has already been fixed in the svn version
Comment 9 Marc Cramdal 2005-09-01 11:26:31 UTC
>Kopete does sent theses event even if they are not asked (i'm not sure about that)  because of a lack in libiris
>By reading the JEP22 , i don't know if it's against the XMPP protocol to do that,  conform client implementation should ignore unknown tag (i think) 

Kopete only sends notifications when they are requested (it fully respects JEP-22). AFAIK if you use current svn Kopete and old Kopete, the old Kopete doesn't get the notifications ;-)

You can disable the notification request in Jabber account configuration, then Privacy tab.

Marc.
Comment 10 Raymond Lewis Rebbeck 2005-09-01 12:01:37 UTC
Any chance of a backported patch for KDE 3.4.x users?
Comment 11 Pali Rohár 2009-06-22 20:08:23 UTC
SVN commit 985395 by pali:

Added option to merge all messages from all jabber contact's resources (default enabled)

BUG: 111537
BUG: 142650
BUG: 175078
BUG: 194808


 M  +10 -0     jabberaccount.cpp  
 M  +10 -0     jabberaccount.h  
 M  +12 -3     jabbercontact.cpp  
 M  +7 -0      ui/dlgjabbereditaccountwidget.ui  
 M  +4 -0      ui/jabbereditaccountwidget.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=985395
Comment 12 Matt Rogers 2009-06-25 19:13:16 UTC
SVN commit 987171 by mattr:

Added option to merge all messages from all jabber contact's resources (default enabled)

recommit for pali now that trunk is open. This will be in KDE 4.4

BUG: 111537
BUG: 142650
BUG: 175078
BUG: 194808


 M  +10 -0     jabberaccount.cpp  
 M  +10 -0     jabberaccount.h  
 M  +12 -3     jabbercontact.cpp  
 M  +7 -0      ui/dlgjabbereditaccountwidget.ui  
 M  +4 -0      ui/jabbereditaccountwidget.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=987171