Bug #244
Messages from other party not received when chat started from Beem
Description
When I start a chat from Beem, I don't receive messages from the other party, but if the other party starts a chat, it works fine.
To reproduce:
- Start Beem and log in
- Click on a contact to start a chat
- Send a message (the contact will receive this)
- Any response from the contact will not show up
I added some debug messages and re-compiled, and I believe this is what is happening:
When a chat is started with Beem, the participant passed to smack is "user@example.com", with no resource appended. When the user replies, smack starts a new chat with the participant "user@example.com/resource". Beem strips the resource when it looks up the existing chat, so it knows not to start a new chat. However, the problem is that smack has created two chats, and Beem has only associated its chat object with smack's first chat object (the one created for the outgoing chat with no resource appended).
If, however, the remote user starts the chat, then only one chat object is created (for the incoming message from "user@example.com/resource") and everything works.
I added a debugging message to BeemChatManager.ChatListener.chatCreated that shows what's going on:
(click on contact in Beem to start chat)
D/BeemChatManager( 1103): Get chat key = user@example.com
V/BeemChatManager( 1103): chat created locally org.jivesoftware.smack.Chat@437c5090 participant user@example.com
I/ActivityManager( 570): Displayed activity com.beem.project.beem/.ui.Chat: 284 ms
(remote user sends a message)
V/BeemChatManager( 1103): chat created non-locally org.jivesoftware.smack.Chat@437f7cd0 participant user@example.com/resource
I tested this with a locally compiled Beem from revision 673, ejabberd, and pidgin.
Related issues
Updated by Frédéric Barthéléry about 14 years ago
- Status changed from New to Assigned
- Assignee set to Frédéric Barthéléry
We should not create the Chat before sending a message to the user. (Note : if we send a message the problem doesn't appear). However I have not figure yet how to deal properly with open chat window. For example :
- we open the chat activity for contact user@example.com
- user@example.com/res send us a message. We should display it on the open chat activity instead of displaying a notification.
Updated by Frédéric Barthéléry about 14 years ago
- Status changed from Assigned to Resolved
- % Done changed from 0 to 100
Applied in changeset r675.
Updated by Jerome M. about 14 years ago
Hello,
It seems like the bug is still present for me... :(
Updated by Nikita Kozlov about 14 years ago
jer mar wrote:
Hello,
It seems like the bug is still present for me... :(
Are you sure that you have the last repository version ?
Updated by Jerome M. about 14 years ago
well, I triple checked that, verified md5sum of built and installed packages... I'm pretty sure now...
Updated by Frédéric Barthéléry about 14 years ago
- Status changed from Resolved to Feedback
- Target version set to 0.2
- % Done changed from 100 to 80
From the r675 changeset, there is normally only one chat created.
The chat activity now create the smack Chat object only when we are sending a message first.
I cannot reproduce your bug anymore. Could you try to get a little more details on this ?
Updated by Jerome M. about 14 years ago
It seems like the problem is the same as described by James regarding the resource when creating the chat. One is created locally when sending the first message from beem, and another one is created when replying from the other client (empathy here) Here is an extract of my logs:
I/ActivityManager( 108): Displayed activity com.beem.project.beem/.ui.Chat: 266 ms (total 266 ms)
D/BeemChatManager( 760): Get chat key = jahrome@server
D/BeemChatManager( 760): Chatorg.jivesoftware.smack.Chat@45f36048 created locally truewith jahrome@server
I/FieldContext( 198): Bundle = Bundle[{imeOptions=1073741828, packageName=com.beem.project.beem, inputType=163905, hint=Type your message, label=, fieldName=, fieldId=2131361809, singleLine=false}]
D/BeemChatManager( 760): Chatorg.jivesoftware.smack.Chat@45f87e60 created locally falsewith jahrome@server/Telepathy.572f9ef8
D/dalvikvm( 542): GC freed 2673 objects / 139120 bytes in 91ms
Updated by Frédéric Barthéléry about 14 years ago
Can you check the jabber log of empathy and see if empathy responds to beem with a message containing the samedi thread element. If not this may be a bug in empathy.
Updated by Jerome M. about 14 years ago
I have troubles understanding what samedi is... could you clarify tis point ?
Empathy does not generate such logs, I tried with pidgin and it is the same issue as it appends a ressource id :
D/BeemChatManager( 949): Chatorg.jivesoftware.smack.Chat@45f9c258 created locally falsewith jahrome@server/24c480416ba8300d08edc50a743c0b4c60f7eb95
Hope this help
Updated by Nikita Kozlov about 14 years ago
jer mar wrote:
I have troubles understanding what samedi is... could you clarify tis point ?
Empathy does not generate such logs, I tried with pidgin and it is the same issue as it appends a ressource id :D/BeemChatManager( 949): Chatorg.jivesoftware.smack.Chat@45f9c258 created locally falsewith jahrome@server/24c480416ba8300d08edc50a743c0b4c60f7eb95
Hope this help
samedi is the french world for saturday.
Updated by Frédéric Barthéléry about 14 years ago
jer mar wrote:
I have troubles understanding what samedi is... could you clarify tis point ?
Sorry completion error. I was thinking about the same thread. Pidgin haver a console that can display the XMPP message exchanged with the server. Maybe empathy got one too.
Updated by Jerome M. about 14 years ago
here is the jabber log from pidgin:
(15:28:14) jabber: Recv (278): <message xmlns='jabber:client' type='chat' from='test@server/Beem' to='jahrome@server/045539a5bf1a21e3cbd97bd34f4a22d70e71f5d1' id='K2XDV-11'><subject/><body>test message</body><thread>iCehk5</thread><active xmlns='http://jabber.org/protocol/chatstates'/></message>
(15:28:19) jabber: Sending: <message type='chat' id='purpled922a18a' to='test@server/Beem'><composing xmlns='http://jabber.org/protocol/chatstates'/></message>
(15:28:20) jabber: Unable to find caps: nothing known about buddy
(15:28:20) jabber: Sending: <message type='chat' id='purpled922a18b' to='test@server/Beem'><active xmlns='http://jabber.org/protocol/chatstates'/><body>reply message</body></message>
(15:28:20) jabber: Sending: <message type='chat' id='purpled922a18c' to='test@server/Beem'><active xmlns='http://jabber.org/protocol/chatstates'/></message>
Updated by Frédéric Barthéléry about 14 years ago
So this is a little bug in pidgin and empathy, maybe in the libpurble.
According to the rfc3921,
The value of the <thread/> element is generated by the sender and SHOULD be copied back in any replies.
They don't answer with the thread element so smack thinks it is another chat. I will make a little patch for smack to force it to deliver the message to the chat conversation for the same bare jid (without the resource).
Updated by Frédéric Barthéléry about 14 years ago
The bug should normally be fixed by the new asmack library with a custom patch in r696
Updated by Anonymous about 14 years ago
Same problem here. The porblem only started after the last update. Could you please offer the previous version in the Market until this issue is fixed. The previous version was working fine for me.
Thanks.
Updated by Nikita Kozlov about 14 years ago
It's not surprising me since I make a lot of changes in chat's related classes.
I will take a look on it this afternoon.
I hope we will manage to fix this bug before the next release.
Updated by Nikita Kozlov about 14 years ago
- Status changed from Feedback to Assigned
- Assignee changed from Frédéric Barthéléry to Nikita Kozlov
Updated by Frédéric Barthéléry about 14 years ago
You can download the older version of Beem here. You can install it with a file manager for Android or using the android sdk.
You can also try the nigtly build where the bug should be fixed : http://dev.beem-project.com/Beem-debug.apk
Please report any change on this.
Updated by Frédéric Barthéléry about 14 years ago
- Status changed from Assigned to Resolved
- Target version changed from 0.2 to 0.1.3