Closed Bug 347456 Opened 18 years ago Closed 16 years ago

Messages with a mode prefix should be recognizable as such

Categories

(Other Applications :: ChatZilla, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

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

Details

(Whiteboard: [cz-0.9.80])

Attachments

(1 file)

The fix for bug 330990 means that messages with a prefix now get displayed normally, but this means they're no longer distinguishable - meaning there's no way to tell they were only sent to voiced/halfopped/opped users.

One way to fix this would be to have a separate tab. I don't particularly like this idea, but it's possible.

Personally, I thought it would be nice to show the userlist icon for the prefix, if possible (and otherwise just the text prefix). I think this should be possible using some attributes and fancy CSS (though I will immediately admit I haven't looked into the technical details of it). So messages to halfops and above would get a blue light or % sign next to it, depending on the pref for showing icons in the userlist, etc. For prefixes that we don't know of (does the *cough* 'spec' *cough* allow that?), we could use text only.
Confirmed. This could be a privacy concern also - not knowing that a message was meant to be private could lead to its contents being inadvertently revealed by the recipient, or inadvertently replied to in public.

As for the spec, I'd suggest supporting @ and +, and anything the RPL_ISUPPORT says is present.
Status: UNCONFIRMED → NEW
Ever confirmed: true
We've discussed possible ways to show the special status of these kinds of messages in #chatzilla more times than I can to count, but I think the following are the general conclusions:
 - Displaying anything as text as a prefix to the message text is trivial to
   spoof (by simply typing it in yourself) and therefore not suitable.
 - Displaying an image, or image and text, as a prefix is better, but it is
   tricky to use the right image and you're stuffed if the server has a user
   mode prefix not in our set of images.
 - Displaying text in the nickname column but outside of the <...> is
   cumbersome and has issues with motifs which hide the < and >.
 - Displaying text in the nickname column inside the <...> seems the most
   plausible at this time.

So, to expand on the final one:
 - WALLOPS would appear on the network view as either:
     <nick/wallops> Hi! I'm an IRCop who can send WALLOPS!
     </wallops> Hi! I'm a server who can send WALLOPS!
 - Mode prefix messages would appear in the channel view as:
     <nick/@> Hi to all ops in the channel!
     <nick/%> Hi to all half-ops in the channel!
   Etc..

The "/" and following text would not be part of the nickname link (if there is a nickname) and neither would they be part of the ">" <SPAN> which may be hidden by motifs. A motif which hid the < and > would therefor show "nick/@", etc. instead.

Nothing is fixed in stone, but this seems to be a reasonable solution and is not excessively hard to implement either. We still need to decide on what msgtype to use for each case and how we will communicate the suffix to the __display code.
Assignee: rginda → silver
QA Contact: samuel → chatzilla
Status: NEW → ASSIGNED
This covers both this bug and bug 379087. It changes __display to accept "FOO/BAR" as a msgtype, which it splits into "FOO" as msgtype and "BAR" as msgprefix. It then displays <nick/BAR> or </BAR> as appropriate. Logged as that too.
Attachment #295540 - Flags: review?(gijskruitbosch+bugs)
Comment on attachment 295540 [details] [diff] [review]
Collect and display message prefixes and WALLOPS

>Index: xul/content/handlers.js
>===================================================================
> <snip> 
>+CIRCNetwork.prototype.onWallops =
>+function my_netwallops(e)
>+{
>+    client.munger.getRule(".mailto").enabled = client.prefs["munger.mailto"];
>+    if (e.user)
>+        this.display(e.msg, "WALLOPS/WALLOPS", e.user, this);
>+    else
>+        this.display(e.msg, "WALLOPS/WALLOPS", (void 0), this);

Nit: Why not just |undefined| or even |null| ? Much easier to read.

>+    client.munger.getRule(".mailto").enabled = false;
>+}

<snip>

You mutilated display(), which makes me sad because it'll mean lots of conflicts in my local tree :-(. Other than that, r+ with the nit fixed or explained.
Attachment #295540 - Flags: review?(gijskruitbosch+bugs) → review+
Checked in --> FIXED.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [cz-0.9.80]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: