Closed Bug 349268 Opened 19 years ago Closed 17 years ago

Nickname reclaim botches spaces

Categories

(Other Applications Graveyard :: ChatZilla, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bugzilla-mozilla-20000923, Assigned: Mitch)

References

Details

(Whiteboard: [cz-0.9.82])

Attachments

(2 obsolete files)

When we have a nickname with spaces in, a couple of things get botched: - we try to reclaim the nick, as "Foo Bar" (pref) != "Foo_Bar" (used) - we reclaim using "NICK Foo Bar" (doh) which ends up with just Foo. A few possible solutions, not all mutually exclusive: - patch up default nickname for spaces (case I hit just now) - correct nickname pref when starting a connect - try to patch all [important] pref compares (sucky solution) http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/extensions/irc/xul/content/handlers.js&rev=1.134&mark=2046,2055#2042
Rephrasing this - spaces aren't possible in nicknames, it's entirely out of spec, and as the original reporter indicates, it causes undefined behavior with the nickname reclaim feature and probably elsewhere.
Keywords: polish
Summary: Nickname reclaim botches spaces → Preferences dialog shouldn't allow spaces.
Keywords: polish
Summary: Preferences dialog shouldn't allow spaces. → Nickname reclaim botches spaces
Depends on: 402533
Status: NEW → ASSIGNED
Attached patch Patch v1.0 (obsolete) — Splinter Review
This patch does the following: - fixes existing space-underscore replacements - makes spaces in default nickname replaced with underscores - modifies nickname prompt dialog to replace spaces in nickname with underscores, and changes the dialog text accordingly.
Assignee: rginda → mitch_1_2
Attachment #315801 - Flags: review?(silver)
Severity: minor → normal
Blocks: 363940
Comment on attachment 315801 [details] [diff] [review] Patch v1.0 I'm not convinced the msg.nick.prompt change is necessary, but I'll let that go. >- e.nickname = prompt(MSG_NICK_PROMPT, curNick); >+ e.nickname = prompt(MSG_NICK_PROMPT, curNick).replace(/ /g, "_"); > if (e.nickname == null) > return; prompt() will return |null| if the user was silly enough to cancel. That's what the check afterwards is. If it returns |null|, you'll get a JavaScript error saying |replace is not a function| or something to that effect. I'd suggest this code: e.nickname = prompt(MSG_NICK_PROMPT, curNick); if (e.nickname == null) return; e.nickname = e.nickname.replace(/ /g, "_");
Attachment #315801 - Flags: review?(silver) → review-
Attached patch [checked in] Patch v1.1 (obsolete) — Splinter Review
Attachment #315801 - Attachment is obsolete: true
Attachment #316048 - Flags: review?(silver)
Comment on attachment 316048 [details] [diff] [review] [checked in] Patch v1.1 I'll take that!
Attachment #316048 - Flags: review?(silver) → review+
Comment on attachment 316048 [details] [diff] [review] [checked in] Patch v1.1 Not sure this completely resolves the bug; do we know if it does?
Attachment #316048 - Attachment description: Patch v1.1 → [checked in] Patch v1.1
Attachment #316048 - Attachment is obsolete: true
Whiteboard: [cz-0.9.82]
(In reply to comment #6) > (From update of attachment 316048 [details] [diff] [review]) > Not sure this completely resolves the bug; do we know if it does? > As far as I know, it should. There are currently no other consumers of changeNick, to my knowledge - except for the pref dialog, but that's bug 363940.
Alright, marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Product: Other Applications → Other Applications Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: