From 9447030cd4d3c0ac72da1279ef4a9e35e9efb594 Mon Sep 17 00:00:00 2001 From: Florian Schmaus Date: Mon, 20 May 2024 21:45:47 +0200 Subject: [PATCH] [muc] Do not invoke userHasLeft() on nickname change When the incoming unavailable presence is signalling a nickname change (303), then do not invoke userHasLeft(), because the user actually does not leave but instead just changes its nickname. Note that this would also have had fixed SMACK-942, as it would resolve the deadlock. However, using a dedicated lock for changeNickname() still seems sensible, and if its just to avoid a bit of lock contention. What this also fixes is that a MultiUserChat does no longer invoke its listener-based callbacks after a nickname change, as previously, after a nickname change, the userHasLeft() would have been invoked, which tears down the listeners. This issue was found with MultiUserChatOccupantIntegrationTest.mucChangeNicknameInformationTest(). --- .../java/org/jivesoftware/smackx/muc/MultiUserChat.java | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/smack-extensions/src/main/java/org/jivesoftware/smackx/muc/MultiUserChat.java b/smack-extensions/src/main/java/org/jivesoftware/smackx/muc/MultiUserChat.java index 999a7d306..5c3f687c4 100644 --- a/smack-extensions/src/main/java/org/jivesoftware/smackx/muc/MultiUserChat.java +++ b/smack-extensions/src/main/java/org/jivesoftware/smackx/muc/MultiUserChat.java @@ -258,13 +258,14 @@ public class MultiUserChat { break; case unavailable: occupantsMap.remove(from); - if (mucUser != null && mucUser.hasStatus()) { - if (isUserStatusModification) { + Set status = mucUser.getStatus(); + if (mucUser != null && !status.isEmpty()) { + if (isUserStatusModification && !status.contains(MUCUser.Status.NEW_NICKNAME_303)) { userHasLeft(); } // Fire events according to the received presence code checkPresenceCode( - mucUser.getStatus(), + status, isUserStatusModification, mucUser, from);