message body tag getting empty xmlns set sometimes when BOSH client is in MUC room
Description
Environment
Activity
Tom Evans October 30, 2015 at 9:31 PM
Fixed this issue by using string insert rather than the Element API. See for more info.
Tom Evans October 30, 2015 at 4:11 PM
Regarding the rollback of the fix for OF-938, this will have the unfortunate side effect of breaking the integration for websocket-based clients (e.g. using stanza.io). I will re-open that ticket for further investigation.
Daryl Herzmann October 30, 2015 at 4:02 AM
So I had a suspicion that this change was having some strange side effect
I built Openfire circa 4 August (prior to this change) and could not reproduce this issue.
I then built current master with this patch backed out and could not reproduce this issue either.
Will let ignite run with this build and see if we can make the pot boil again
Daryl Herzmann October 30, 2015 at 3:18 AM
So Gajim gave me better xmlconsole results, this message fails to be displayed by pidgin
While this one does
Strangely, when this happens, a message coming from Pidgin gets 'corrupted' as well
Daryl Herzmann October 30, 2015 at 2:52 AM
Very puzzling, the routing 'seems' to actually be working, but the client (Pidgin) fails to actually display the message in the chatroom! More boggling and testing other clients ahead. Maybe the 'XML' is getting corrupted somehow and the client is ignoring the message. I did capture one packet with
Details
Details
Assignee
Tom EvansReporter
Daryl HerzmannComponents
Fix versions
Priority
Blocker
The original title and description of this bug turned out to be an incorrect summary of the matter. The issue was that some clients (namely Pidgin) would not display messages that have a blank xmls="" on the message->body tag. The exact reason for this happen is not clear, but we tested a patch to resolve this and at the same time.