cburschka / cadence

A strophe.js-powered XMPP web client for chatrooms.
6 stars 2 forks source link

Nick changes with multiple nicks are really broken again. #456

Open cburschka opened 7 years ago

cburschka commented 7 years ago

The first part is a bug in cadence that is exposed by a bugfix in ejabberd, the other part is a new regression in ejabberd.

Problem 1

If you're in the room twice with the same nick "A", and you do /nick B in one of them, then that client will update the roster but not print an "is now known as" or even "has joined the room" message (all other clients will correctly see a new user named "B" joining the room). This is probably a minor logic bug in the presence handler.

Ironically, it's triggered by a bugfix in ejabberd - it only happens if the server correctly includes a "110" status code for the reflected presence. On older ejabberd versions (eg 2.1.10) the code is not included and cadence works right.

Problem 2

If you're in the room three times (twice as "A", once as "B") and you do /nick B in one of the A sessions, the server doesn't acknowledge it at all, even to reflect your presence. (Therefore cadence can't update the roster or notify you, and it will appear as if the command never got sent.)

There's no way to tell that the server received your nick change request, until you send a new message and the server reflects it back to you with "B" instead of "A". You're then left in a state where the client thinks you're A (xmpp.nick == {current: 'A', target: 'B'}) but the server thinks you're B.

Problem 3

ejabberd doesn't guarantee the order in which presences are sent (and this is not technically wrong).

If by chance the new presence arrives before the unavailable presence does, cadence will generate two notifications. That's wrong.

cburschka commented 7 years ago

Linking the ejabberd issue: https://github.com/processone/ejabberd/issues/1392