Closed
Bug 349268
Opened 19 years ago
Closed 17 years ago
Nickname reclaim botches spaces
Categories
(Other Applications Graveyard :: ChatZilla, defect)
Other Applications Graveyard
ChatZilla
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
Comment 1•19 years ago
|
||
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.
Reporter | ||
Updated•19 years ago
|
Keywords: polish
Summary: Preferences dialog shouldn't allow spaces. → Nickname reclaim botches spaces
Assignee | ||
Updated•17 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•17 years ago
|
||
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)
Assignee | ||
Updated•17 years ago
|
Severity: minor → normal
Reporter | ||
Comment 3•17 years ago
|
||
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-
Assignee | ||
Comment 4•17 years ago
|
||
Attachment #315801 -
Attachment is obsolete: true
Attachment #316048 -
Flags: review?(silver)
Reporter | ||
Comment 5•17 years ago
|
||
Comment on attachment 316048 [details] [diff] [review]
[checked in] Patch v1.1
I'll take that!
Attachment #316048 -
Flags: review?(silver) → review+
Reporter | ||
Comment 6•17 years ago
|
||
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
Reporter | ||
Updated•17 years ago
|
Whiteboard: [cz-0.9.82]
Comment 7•17 years ago
|
||
(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.
Reporter | ||
Comment 8•17 years ago
|
||
Alright, marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•4 months ago
|
Product: Other Applications → Other Applications Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•