Firestorm: Allows blocked residents to spam via objects

[Paul Hexem]

4 hours ago, Beq Janus said:

processMuteListUpdate()

Are we thinking there's an error reading the list before the llInstantMessage?

Just for chuckles I'm going to wipe my entire list (minus the current problem person) prior to this weekend and see if it makes a difference.

[Beq Janus]

1 hour ago, Paul Hexem said:

Are we thinking there's an error reading the list before the llInstantMessage?

Just for chuckles I'm going to wipe my entire list (minus the current problem person) prior to this weekend and see if it makes a difference.

Not necessarily. I've had another person test the same scenario as @Quistess Alpha and I, and like me they block normally and as expected. I am currently building a viewer with some extra logging in it that might help us identify at what point the viewer gives up and says screw it, let it through. There are a lot of checks and conditions for whether a message is allowed through, RLV, friends only, mutelist, etc etc, so now I am wondering if you have some magic combination of settings that is doing this (or I have the magic ones that make it work) 

 

[Paul Hexem]

7 minutes ago, Beq Janus said:

Not necessarily. I've had another person test the same scenario as @Quistess Alpha and I, and like me they block normally and as expected. I am currently building a viewer with some extra logging in it that might help us identify at what point the viewer gives up and says screw it, let it through. There are a lot of checks and conditions for whether a message is allowed through, RLV, friends only, mutelist, etc etc, so now I am wondering if you have some magic combination of settings that is doing this (or I have the magic ones that make it work) 

 

Thanks again for the effort on it.

I do have RLV enabled in the viewer itself, but the only RLV stuff I wear is an item I scripted myself to do some teleports via some of my own devices. I can't imagine it's having an impact other than, like you said, some odd combination that triggers a glitch. Next step I suppose is to export my settings into that JIRA.

[Henri Beauchamp]

6 hours ago, Beq Janus said:

I was expecting to see at least a processMuteListUpdate() for the initial response though.

This method is called in reply to the UDP message sent from LLMuteList::requestFromServer(), which is itself only called once after login. There are a few seconds of delay between the request and the reply, meaning that there could be a race condition, sometimes, when a messages arrives in real time during the login from a muted object or avatar, before the mute list has been received from the server.

For this reason, and also because the server could possibly glitch, sometime (or UDP messages could get lost), and as well because I extended the mute feature (more combinations, fine grained mutes) in my viewer and the mute list extra bits could get 'corrupted' should the user use another viewer and update mutes from it in between two Cool VL Viewer sessions, I implemented a local (per account) mute list file for the Cool VL Viewer (which is different from the cached mute file) which I load at the same time as I send requestFromServer()...

As for the updates to the mute list done during a viewer session, they are sent to the server via LLMuteList::updateAdd() and LLMuteList::updateRemove() which send the corresponding UDP messages, but the latter do not trigger any reply/callback from the server.

Edited June 27, 2023 by Henri Beauchamp

[Beq Janus]

1 minute ago, Paul Hexem said:

Thanks again for the effort on it.

I do have RLV enabled in the viewer itself, but the only RLV stuff I wear is an item I scripted myself to do some teleports via some of my own devices. I can't imagine it's having an impact other than, like you said, some odd combination that triggers a glitch. Next step I suppose is to export my settings into that JIRA.

I have a custom build, but as don't know if you are able to repro like Tessa can it doesn't move us forward

[Beq Janus]

OK problem has been located. You will kick yourselves when you see it. The blocks are working entirely as designed. 

You have enabled the "show muted chat" button. In the example below, GreenSpammer is blocked, YellowSpammer is not. 

It is remarkably obvious in hindsight, but I've never clicked the button, so learned something new today, too LOL

 

 

[Paul Hexem]

That's... crazy.

I immediately ask myself how that got enabled to begin with, and why it's even an option, and why it doesn't stand out as different than regular chat...

Created more questions for me, but at least we found the problem.

[Beq Janus]

54 minutes ago, Paul Hexem said:

That's... crazy.

I immediately ask myself how that got enabled to begin with, and why it's even an option, and why it doesn't stand out as different than regular chat...

Created more questions for me, but at least we found the problem.

How it got enabled is almost certainly "you clicked it", probably not intentionally, maybe you were trying to click history or something, if there was no muted text on screen then you'd have seen no change except the subtle highlight and forgotten all about it.

As for differentiation, for muted avatars it will be different. See preferences->colours->muted. But in this case, the fact it is an object supercedes the fact it is muted. For all I know there was a previous JIRA a decade ago asking for that. 

As to why it is a button at all? I have no idea, I never even knew it was one. It has been there for a long time, though, and this is the first I have ever heard of it causing an issue, so I am going to have trouble arguing that it is a problem 🙂

However, I have made it so that it will not persist, that way the worst case is you'll be confused until you relog. The other option is to add yet another colour and I don't think that is worth the hassle

And, of course, thank you for helping get to the bottom of it. Today we all learned something new 🙂 

 

 

Edited June 28, 2023 by Beq Janus

[Henri Beauchamp]

6 hours ago, Beq Janus said:

The other option is to add yet another colour and I don't think that is worth the hassle

In v1 viewers, when enabled, the muted text appears in dark grey, which might be more ”explicit” and intuitive than some colorful (even if dark) text, also the option appears as a ”Show muted text” check box, making it totally clear about what it enables and when it is enabled, unlike the cryptic icon used in v2+ viewers...

That's one of the things I like in the v1 UI: straight to the point, explicit, free of ”graphical noise” (useless or ambiguous icons).

Edited June 28, 2023 by Henri Beauchamp

[Wulfie Reanimator]

7 hours ago, Beq Janus said:

The other option is to add yet another colour and I don't think that is worth the hassle

Or apply the same color to objects owned by muted avatars. 🙂

The non-persistence of that setting is probably the best thing to have in any case.

[Quistess Alpha]

14 hours ago, Beq Janus said:

You have enabled the "show muted chat" button.

Glad we figured it out!

I don't want to be too negative, but this is one of the reasons I really dislike firestorm. A lot of your buttons don't have text on them, so the only way to figure out what they do is to click on them. How am I supposed to know that a thing that looks like an oil lamp is for offering teleports? or that a screen with a red cross means "Please show me text I asked not to see"? at the very least could you also echo a message in local chat saying something like "show muted chat enabled/disabled" when pressing the button?

[Frionil Fang]

1 hour ago, Quistess Alpha said:

How am I supposed to know that a thing that looks like an oil lamp is for offering teleports?

There should be tooltips for nearly everything I can see in Firestorm though. After mousing over my standard view, the only icons that remained unexplained were the parcel properties icons -- things like script and rez permissions, that is (which I'm not sure if they're even shown by default).  Then I spent a while mousing over everything in the other programs I had open and it works just the same everywhere, nearly every program I use will set up tooltips.

I don't think it's a particularly obscure UI feature.

[Quistess Alpha]

11 minutes ago, Frionil Fang said:

There should be tooltips for nearly everything I can see in Firestorm though.

That's a fair point, but it doesn't help the reverse: if I'm looking to teleport someone, It's easier for my eyes to quickly pick the word 'teleport' out of a list than to look for a strange symbol I wouldn't recognize unless I've used it a few times before.

[Frionil Fang]

I get that, I guess I have to admit being very used to the Firestorm style after 13 years (Emerald and Phoenix before it). I like tooltips for condensing UIs but it does add hassle when getting "started".

[Wulfie Reanimator]

1 minute ago, Quistess Alpha said:

That's a fair point, but it doesn't help the reverse: if I'm looking to teleport someone, It's easier for my eyes to quickly pick the word 'teleport' out of a list than to look for a strange symbol I wouldn't recognize unless I've used it a few times before.

Text vs icon with tooltip is a tradeoff in screen real estate. You can find the teleport button (with text) in any person's profile. The small button in an IM window is just a shortcut.

Personally I wouldn't want the chat window to get even bigger because the icons got replaced with words.

(Whether or not the genie lamp is intuitive for a teleport can be its own can of worms. 😋)

[Quistess Alpha]

6 minutes ago, Wulfie Reanimator said:

Text vs icon with tooltip is a tradeoff in screen real estate. You can find the teleport button (with text) in any person's profile. The small button in an IM window is just a shortcut.

Not to labor the point, but I ~do want bigger buttons. Small things are getting harder and harder to press accurately. And, also fair, but I'm never going to offer a teleport to someone who I'm not already talking with. I've never really thought to use the buttons on a person's profile unless it's the 'start IM' button.

Also in kokua, I can right-click the the chat participant's name to bring up a list of things to do with them, no extra 'screen real-estate' required. It often confuses me when I can't do that in firestorm.

Edited June 28, 2023 by Quistess Alpha

[Paul Hexem]

7 hours ago, Henri Beauchamp said:

In v1 viewers, when enabled, the muted text appears in dark grey, which might be more ”explicit” and intuitive than some colorful (even if dark) text

6 hours ago, Wulfie Reanimator said:

Or apply the same color to objects owned by muted avatars. 🙂

I think this is the biggest problem with it. Assuming you accidentally toggle it on (which is easy to do, considering the location and the "toggle" status is barely obvious on some of these skins) there's no differentiating between regular scripted text and muted text.

It's literally so non-intuitive, one of Firestorm's own devs had no idea about it even with screenshots of the UI and wound up putting hours of work into the problem before finding it.

[Rowan Amore]

Don't push buttons if you don't know what they do.  😋

I've used the Show Muted button for as long as I can remember.  

[Paul Hexem]

6 minutes ago, Rowan Amore said:

Don't push buttons if you don't know what they do.

Which is the problem. It's a button that isn't clear when it's on, isn't clear what it does, and is way too easy to misclick.

[Ardy Lay]

[Ardy Lay]

4 hours ago, Paul Hexem said:

Which is the problem. It's a button that isn't clear when it's on, isn't clear what it does, and is way too easy to misclick.

Linden Lab removed that feature from Second Life Viewer some time ago.  I wrote a JIRA in protest because I used that feature so I would not have to purge my block list when it was my day to marshal the stooges.  As a result of losing that feature, it's always my day to marshal the stooges, therefore, they tired of me and left Second Life.

Edited June 28, 2023 by Ardy Lay

[Harpakhruti]

I registered a similar issue, though different. When I go in a place where there is the extended local chat range, muted people keeps to be shown in local chat, or in other words, they keep to speak, despite muted (and the debug settings has nothing to correct that, apparently). I searched the whole options several times in the preferences, and found anything that could barely notice how that can be possible. I am so puzzled.

[Zalificent Corvinus]

2 hours ago, Harpakhruti said:

I registered a similar issue, though different. When I go in a place where there is the extended local chat range, muted people keeps to be shown in local chat, or in other words, they keep to speak, despite muted (and the debug settings has nothing to correct that, apparently). I searched the whole options several times in the preferences, and found anything that could barely notice how that can be possible. I am so puzzled.

You haven't blocked the chat extender, and the chat extender doesn't KNOW who you have blocked, so it cannot block people you blocked.

You problem is caused by objects owned by people you haven't blocked, not being PSYCHIC AND ABLE TO READ MINDS.

This is "Working as Intended".

 

Edited February 18 by Zalificent Corvinus

[AmeliaJ08]

8 hours ago, Harpakhruti said:

I registered a similar issue, though different. When I go in a place where there is the extended local chat range, muted people keeps to be shown in local chat, or in other words, they keep to speak, despite muted (and the debug settings has nothing to correct that, apparently). I searched the whole options several times in the preferences, and found anything that could barely notice how that can be possible. I am so puzzled.

Yeah that is impossible for the viewer to filter since it is being rebroadcast via a script being run in an object owned by someone who does not share your block list.

It's just the way "extended chat range" devices work, they are scripts that are listening and rebroadcasting what people say across the entire parcel (or any defined range the owner sets).

 

Edited February 18 by AmeliaJ08

[Harpakhruti]

On 2/18/2024 at 7:32 AM, Zalificent Corvinus said:

You haven't blocked the chat extender, and the chat extender doesn't KNOW who you have blocked, so it cannot block people you blocked.

You problem is caused by objects owned by people you haven't blocked, not being PSYCHIC AND ABLE TO READ MINDS.

This is "Working as Intended".

 

Thanks, I'll try that blocking and see if that might work!