Closed Bug 788137 Opened 8 years ago Closed 6 years ago
Nick for XMPP chatrooms becomes 'null'
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1 Steps to reproduce: Create XMPP account Choose "Join Chat" Enter room, server and a custom nickname Select 'Auto-join this chat room' Actual results: Upon reconnecting, the nickname is set to 'null'. In the accounts dialog, there's a "/null" at the end of the room. Simply replacing this did not seem to fix the problem. Expected results: The nick that was previously specified should have been saved. Nicks containing spaces should be supported, too. (I tried both variants)
Just tried it with the Earlybird release. Changing the nickname at the end of the channel name in the accounts dialog seems to work now. It is still set to 'null' when first joining the channel though.
I just tried to reproduce this and couldn't. Can you still reproduce this? If you can, could you please give more detailed steps to reproduce? Thanks!
I have the same issue with 17.05. When I first join everything is fine, but several hours later I become "null" in the room. The only way to fix is to leave the chat room and reconnect, and set the nickname again. I haven't even disconnected from the chat room when this happens.
Same issue. Very annoying. It is working well with pidgin. Please, stop adding features to Thunderbird, and fix bugs first.
(In reply to Andre Rodier from comment #5) > Same issue. Very annoying. Could you please provide detailed steps to reproduce the issue?
Same here. Steps to reproduce: 1. Create jabber account 2. Connect 3. join chat, fill parameters, check join on connect checkbox The /null configuration is now persisted.
(In reply to Thorsten S. from comment #7) > Same here. Steps to reproduce: > > 1. Create jabber account > 2. Connect > 3. join chat, fill parameters, check join on connect checkbox > > The /null configuration is now persisted. Which server are you using? (Of course, if you don't wish to share that information, that's OK, but it would help to reproduce this.) Does this only happen if you pick a different nick for the chatroom than your XMPP name (what's in front of the @ in your JID) or doesn't that make any difference? Are there any special characters in your nick?
Same bug with debianforum.de:5222 and our local company jabber server. The nick can differ or not, the nick part will be null (tested again). My nick(s) consists of 4-8 simple ascii characters, tested mixed case and lower case.
Component: Instant Messaging → XMPP
OS: Windows 8 → All
Product: Thunderbird → Chat Core
Hardware: x86_64 → All
Version: 15 → trunk
STR: Join an XMPP MUC from the Join Chat dialog, checking the autojoin box. Then look at the autojoin pref value. The nick is always saved as "null". I'll add a port for TB if you agree with this fix. (I dislike it but can't think of anything better.)
Forgot to ask: I think we could do without the protoId checks altogether here (now we check for the presence of the value), which would make this less ugly. Am I overlooking something?
So I looked at this briefly...this is pretty hacky. I think the right way to do this would be to add an nsISimpleEnumerator of prplIChatRoomFieldValues to the imIAccount (not the prplIAccount, just to be clear) under a field called "autoJoinRooms" or something. This could then be serialized to disc and reloaded each time. This would allow us to be "smarter" about what we actually save from each joined channel. Note that this would also mean the auto-join field is no longer just a string...so that's quite a bit more of an invasive change (but would be a huge jump toward session restore). I have to think about whether we'd want to accept this hack or not, so this definitely isn't an f-, but more of the "perfect" way to do it.
I noticed we return early if the prpl isn't irc, jabber or gtalk anyway, so my idea in comment 11 is ok to make this slightly less ugly. I agree with comment 12 in that this isn't the ultimate solution, but it fixes the bug with the existing autojoin mechanism. Ceterum censeo autojoin esse delendam, etc. Should this be uplifted to TB31?
Comment on attachment 8448615 [details] [diff] [review] nullnick.diff 2 (In reply to aleth [:aleth] from comment #13) > Should this be uplifted to TB31? Yes, please :-).
Attachment #8448615 - Flags: review?(clokep) → review+
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.6
aleth: We want to request approval for beta on this, right?
(In reply to Patrick Cloke [:clokep] from comment #16) > aleth: We want to request approval for beta on this, right? Yes. It would be nice if one of the bug reporters could confirm this fixes the problem for them as well (with the next Instantbird nightly or TB Daily build).
(In reply to aleth [:aleth] from comment #17) > It would be nice if one of the bug reporters could confirm this fixes the > problem for them as well (with the next Instantbird nightly or TB Daily > build). Which versions of the below linked, and when? "Daily" has no checkins in this week, so it says. I'd volunteer.  http://forums.mozillazine.org/viewtopic.php?f=29&t=2850329
Yes, you want the latest Daily: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/
works for me, thanks a lot for your commitment.
Verified per comment 20.
Status: RESOLVED → VERIFIED
Component: XMPP → Instant Messaging
Product: Chat Core → Thunderbird
Target Milestone: 1.6 → ---
Version: trunk → Trunk
Comment on attachment 8448615 [details] [diff] [review] nullnick.diff 2 [Approval Request Comment] User impact if declined: This is an annoying bug for anyone using XMPP autojoins. Testing completed (on c-c, etc.): Verified fixed Risk to taking this patch (and alternatives if risky): Low risk
(In reply to aleth [:aleth] from comment #22) > [Approval Request Comment] > User impact if declined: This is an annoying bug for anyone using XMPP > autojoins. This bug has been reported several times by several different people since we initially released Chat in Thunderbird. Now that we have identified the cause and have a simple fix, I think we should ship it in the next Thunderbird release.
You need to log in before you can comment on or make changes to this bug.