Distinguish muted users in UI #1429

sm-sayedi · 2025-03-21T18:58:23Z

Note: This PR is rebased on top of #1530.

This PR aims to respect the user's settings for muting other users by distinguishing its related UI appearance. From the list of places in UI mentioned in https://zulip.com/help/mute-a-user, the following are included as they're compatible with the current scope of mobile:

Combined feed sent by muted users, including the name, profile picture, and message content, are hidden behind a Click here to reveal banner. A revealed message can later be re-hidden.

Message from muted user (Before)	Message from muted user (After)

Revealed muted message	Revealed muted message (Long-pressed)

Muted users have their name displayed as "Muted user" for emoji reactions, polls, and when displaying the recipients of group direct messages.

Emoji reactions \| Poll (Before)	Emoji reactions \| Poll (After)

Group DMs with muted user (Before)	Group DMs with muted user (After)

Recent DMs view (Before)	Recent DMs view (After)

Recent conversations and other features that display avatars will show a generic user symbol in place of a muted user's profile picture.

Custom profile field (Before)	Custom profile field (After)

Muted users are excluded from the autocomplete for ~~composing a direct message or~~ mentioning a user.

Fixes: #296

sm-sayedi · 2025-05-22T17:37:04Z

@chrisbobbe This is now ready for a general review, as we discussed on the call this week. PTAL.

I am now starting to write tests.

sm-sayedi · 2025-05-22T17:42:23Z

assets/icons/person.svg

@@ -0,0 +1,3 @@
+<svg width="18" height="20" viewBox="0 0 18 20" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path fill-rule="evenodd" clip-rule="evenodd" d="M9 1.9975C6.78948 1.9975 4.9975 3.78948 4.9975 6C4.9975 8.21052 6.78948 10.0025 9 10.0025C11.2105 10.0025 13.0025 8.21052 13.0025 6C13.0025 3.78948 11.2105 1.9975 9 1.9975ZM12.6361 10.77C14.0714 9.67415 14.9975 7.94523 14.9975 6C14.9975 2.68767 12.3123 0.00250244 9 0.00250244C5.68767 0.00250244 3.0025 2.68767 3.0025 6C3.0025 7.94523 3.92857 9.67415 5.36389 10.77C4.3572 11.2147 3.43107 11.8445 2.63781 12.6378C0.950451 14.3252 0.00250244 16.6137 0.00250244 19C0.00250244 19.5509 0.449098 19.9975 1 19.9975C1.55091 19.9975 1.9975 19.5509 1.9975 19C1.9975 17.1428 2.73526 15.3617 4.04849 14.0485C5.36171 12.7353 7.14282 11.9975 9 11.9975C10.8572 11.9975 12.6383 12.7353 13.9515 14.0485C15.2647 15.3617 16.0025 17.1428 16.0025 19C16.0025 19.5509 16.4491 19.9975 17 19.9975C17.5509 19.9975 17.9975 19.5509 17.9975 19C17.9975 16.6137 17.0496 14.3252 15.3622 12.6378C14.5689 11.8445 13.6428 11.2147 12.6361 10.77Z" fill="black"/>
+</svg>


This icon file is displayed differently when used as ZulipIcon. In the file, the head section is an outlined circle, but in the app, it is a filled circle.

Yeah, fill-rule="evenodd" doesn't work when converted to a font. Here's instructions for fixing it:
https://zulip.readthedocs.io/en/latest/subsystems/icons.html#correcting-icons-with-an-evenodd-fill-rule

chrisbobbe · 2025-05-23T23:05:56Z

Thanks, glad to see this progress on this helpful feature!

Comments on the first four commits:

451ec5a api: Add InitialSnapshot.mutedUsers
0e1259d user: Add UserStore.mutedUsers and helper methods
4b8e1b5 api: Handle muted_users event
bbf9f9c icons: Add "person", "eye", and "eye_off" icons

Let's put the API-binding changes in their own api: commits (one for the initial snapshot, one for the event), then after those, just one user: commit that adds UserStore.mutedUsers / helper methods and also handles MutedUsersEvent. The earlier api: commit that creates MutedUsersEvent will need something like this to satisfy the analyzer:

      case MutedUsersEvent():
        // TODO handle

but that's easy to do. 🙂

Then please send those revised commits as a new, non-draft PR and label it for Greg's review:

Add the "integration review" label
Set the "assignees" and "reviewers" metadata

Thanks! I'll start reading the later commits now.

chrisbobbe

And here's a review of the next commit 🙂:

7072228 msglist: Distinguish messages sent by muted users

chrisbobbe · 2025-05-24T00:19:56Z

lib/widgets/message_list.dart

+class PossibleMutedMessage extends InheritedWidget {
+  const PossibleMutedMessage({
+    super.key,
+    required this.changeMuteStatus,
+    required super.child,
+  });
+
+  final ValueChanged<bool> changeMuteStatus;
+
+  @override
+  bool updateShouldNotify(covariant PossibleMutedMessage oldWidget) => false;
+
+  static PossibleMutedMessage of(BuildContext context) {
+    final value = context.getInheritedWidgetOfExactType<PossibleMutedMessage>();
+    assert(value != null, 'No PossibleMutedMessage ancestor');
+    return value!;
+  }
+}


Interesting; the ValueChanged typedef was new to me!

I think a different approach would be worthwhile, though, toward more familiar/transparent state management and to minimize added code in _MessageListPageState.build.

On MessageListPageState, add methods like the following:

/// The "revealed" state of a message from a muted sender. /// /// See also: [revealMutedMessage], [unrevealMutedMessage]. bool isMutedMessageRevealed(int messageId); /// For a message from a muted sender, reveal the sender and content, /// replacing the "Muted sender" placeholder. void revealMutedMessage(int messageId); /// For a message from a muted sender, hide the sender and content again /// with the "Muted sender" placeholder. void unrevealMutedMessage(int messageId);

Implement these in _MessageListPageState, backed by a Set of message IDs. The implementations should be simple and don't need to involve the store or any event handling; just simple add/remove/read.

Read the dartdoc on MessageListPage.ancestorOf and the implementation comment under it. Since we'll need to call this from a build method, make a prep commit that creates an InheritedWidget, so that ancestorOf can become something like:

/// The [MessageListPageState] above this context in the tree. /// /// Uses the efficient [BuildContext.dependOnInheritedWidgetOfExactType], /// so this may be called in a build method. static MessageListPageState ancestorOf(BuildContext context) { final state = context .dependOnInheritedWidgetOfExactType<_MessageListPageInheritedWidget>() .state; assert(state != null, 'No _MessageListPageInheritedWidget ancestor'); return state!; }

Ah—in fact I think it might need to be an InheritedNotifier, with the reveal…/unreveal… methods calling notifyListeners, so that widgets update when isMutedMessageRevealed has a new value?

HideMutedMessageButton (perhaps renamed UnrevealMutedMessageButton for consistency) can just do this in its onPressed:

MessageListPage.ancestorOf(pageContext).unrevealMutedMessage(message.id);

The "Reveal" button in the message list can do this:

MessageListPage.ancestorOf(context).revealMutedMessage(message.id);

And the UI state in _MessageWithPossibleSenderState.build can use MessageListPage.ancestorOf(context).isMutedMessageRevealed.

Implement these in _MessageListPageState, backed by a Set of message IDs. The implementations should be simple and don't need to involve the store or any event handling; just simple add/remove/read.

I started to refactor the code based on the suggested changes, but it's getting complex; maybe I am not doing it the right way. Also, I think we still need store to react to live changes via MutedUsersEvent.

chrisbobbe · 2025-05-24T00:23:40Z

assets/l10n/app_en.arb

+  "revealButtonLabel": "Reveal message for muted sender",
+  "@revealButtonLabel": {
+    "description": "Label for the button revealing hidden message from a muted sender in message list."
+  },


This feels verbose; how about just "Reveal message"? The sender row already says "Muted sender".

chrisbobbe · 2025-05-24T00:24:52Z

assets/l10n/app_en.arb

+  "mutedSender": "Muted sender",
+  "@mutedSender": {
+    "description": "Name for a muted user to display in message list."
+  },


How about "Muted user"? The fact that it's the sender is already communicated by the position of this text.

I think "Muted user" is better for the reason you mentioned, and I think Web should also consider using this phrase in #34794.

Ooh good thought; I've left a comment there. Thanks for noticing!

chrisbobbe · 2025-05-24T00:28:32Z

assets/l10n/app_en.arb

@@ -128,6 +128,10 @@
  "@actionSheetOptionMarkAsUnread":  {
    "description": "Label for mark as unread button on action sheet."
  },
+  "actionSheetOptionHideMutedMessage": "Hide muted message again",


msglist: Distinguish messages sent by muted users

Commit-message nit: no Fixes: line until a later commit, when all of the issue's work is done :)

chrisbobbe · 2025-05-24T00:31:12Z

lib/widgets/content.dart

+class AvatarPlaceholder extends StatelessWidget {
+  const AvatarPlaceholder({super.key, this.size});
+
+  final double? size;


If all callers pass size, let's make it required

chrisbobbe · 2025-05-24T00:41:20Z

lib/widgets/content.dart

+        // Scale the icon proportionally to match the Figma design.
+        size: size != null ? size! * 20 / 32 : null,


What's the meaning of the size param, and why isn't it used directly here? When I read this I wonder why callers don't just pass the size they want (e.g. from a Figma frame) and expect it to be applied faithfully :)

Ah I think I see: size is really about the dimensions of the square gray box, and the icon is meant to be some fraction of that, right?

Oh, but a nuance: the actual size of the box is controlled by AvatarShape, which callers are supposed to use as a wrapper. So I think the size param calls for a dartdoc explaining why it's needed; something like:

/// The size of the placeholder box. /// /// This should match the `size` passed to the wrapping [AvatarShape]. /// The placeholder's "person" icon will be scaled proportionally to this.

Then here, on the arithmetic, an implementation comment like:

// Where the avatar placeholder appears in the Figma, // this is how the icon is sized proportionally to its box.

chrisbobbe · 2025-05-24T01:01:41Z

lib/widgets/theme.dart

+    required this.grey250,
+    required this.grey550,


Ah, these aren't Figma design variables in the usual way—

—they're part of a "color palette" (see #831).

Since the Figma doesn't seem to offer a variable, let's first see how these look in dark mode (please post screenshots); if they look reasonable (even if not perfect), I'd just hard-code the colors inline, with a TODO(design): dark-mode variant?. If we need a dark-mode variant, please @-mention Vlad in #mobile.

I think these colors should look good in dark mode too, but for some reason, they don't. In dark mode, these colors seem to be changing, even though we use the same colors for the two modes in theme.dart.

Light Dark

Screen.Recording.2025-06-06.at.6.35.29.AM.mov

Looking at #831, which will pull those colors automatically, should we remove them from theme.dart and use them inline for now?

Does it look OK if we use listMenuItemBg for the rounded-rectangle background and listMenuItemIcon for the person icon? With a TODO in the widget code like:

// TODO(design) this was ad-hoc, we need a new variable

Here they are in a screenshot from the Figma:

Here are the hex values (from hovering over where it says grey/200 etc.):

Name Light Dark

listMenuItemBg #cbcdd6 #2d303c

listMenuItemIcon #9194a3 #767988

This would mean adding listMenuItemBg and listMenuItemIcon to DesignVariables. It does seem like we can't use the same color for both light and dark theme, and that means we have to use DesignVariables, which enables the smooth animation between light and dark theme.

These look fine on both modes.

Light Dark

But what about using groupDmConversationIconBg and groupDmConversationIcon instead? They also appear in recent DMs page together.

That does seem like a better fit! Thanks for finding those. Since those aren't named variables from the Figma—they're in the section with the comment

// Not named variables in Figma; taken from older Figma drafts, or elsewhere.

—we're free to name them however we want. Could say avatarPlaceholderIcon and avatarPlaceholderBg; I think that would fit these new uses as well as the existing use on the recent-DMs page.

Pushed with these new changes.

chrisbobbe · 2025-05-24T01:03:55Z

lib/widgets/message_list.dart

+    Widget? revealButton;
+    if (showAsMuted) {
+      revealButton = TextButton.icon(
+        onPressed: () {
+          changeMuteStatus(false);
+        },
+        style: TextButton.styleFrom(
+          minimumSize: Size.zero,
+          padding: EdgeInsets.symmetric(vertical: 4, horizontal: 6),
+          tapTargetSize: MaterialTapTargetSize.shrinkWrap,
+          shape: RoundedRectangleBorder(borderRadius: BorderRadius.circular(6)),
+          splashFactory: NoSplash.splashFactory,
+        ).copyWith(
+          backgroundColor: WidgetStateColor.fromMap({
+            WidgetState.pressed: designVariables.neutralButtonBg,
+            ~WidgetState.pressed: designVariables.neutralButtonBg
+              .withFadedAlpha(0),
+          }),
+          foregroundColor: WidgetStateColor.fromMap({
+            WidgetState.pressed: designVariables.neutralButtonLabel,
+            ~WidgetState.pressed: designVariables.neutralButtonLabel
+              .withFadedAlpha(0.85),
+          }),
+        ),
+        icon: Icon(ZulipIcons.eye),
+        label: Text(zulipLocalizations.revealButtonLabel,
+          style: TextStyle(fontSize: 16, height: 1)
+            .merge(weightVariableTextStyle(context, wght: 600))));
+    }


With 20+ lines of code, this would be good to pull out into a separate widget or a helper method

alya · 2025-05-29T17:39:29Z

"Reveal message for muted sender" is an odd phrase. I think @terpimost 's design just had "Reveal":

Was this changed because we decided to put the button on a separate line from the sender? Even so, maybe "Reveal message" is best -- I think it'll be clear enough.

chrisbobbe

Here's another thought, from looking again at #296: can we centralize the code that chooses "Muted user" to replace a user's name?

Because the list of places that should be affected is so long, we should find ways to encapsulate many of those to go through a much smaller number of distinct places in the source code; otherwise it'll be very easy to miss some, and to forget this feature when adding new pieces of UI that happen to show a user's name or avatar.

What do you think of this commit sequence:

In one commit (or more if it gets complicated), make sure store.userDisplayName and store.senderDisplayName are used in all places that show a user's name
Adjust store.userDisplayName and store.senderDisplayName so they give "Muted user" (translated) when the user is muted. If any callers still want the real name when the user is muted, you can add a param like replaceIfMuted(default true).
Other commits that change how we show muted users, like the reveal/unreveal logic for messages in the message list
Commits that exclude muted users from the UI
- There's another of these: the web app excludes muted users in the typing-status row in the message list; let's do that too.

chrisbobbe · 2025-06-01T00:08:32Z

assets/l10n/app_en.arb

@@ -947,6 +947,10 @@
  "@revealButtonLabel": {
    "description": "Label for the button revealing hidden message from a muted sender in message list."
  },
+  "mutedUser": "Muted user",
+  "@mutedUser": {
+    "description": "Name for a muted user to display all over the app."


nit: how about "Text to display in place of a muted user's name"

(I think "all over the app" isn't very actionable for translators; the important thing is that it replaces strings like "Chris Bobbe", "Greg Price" etc.; it doesn't matter as much that those strings appear all over the app)

Also renamed "user" to "two_person" to make it consistent with other icons of the same purpose. New icons taken from: https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=5968-237884&t=dku3J5Fv2dmWo7ht-0 https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=5968-264632&t=dku3J5Fv2dmWo7ht-0 https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=5968-291260&t=B5jAmeUMMG4dlsU7-0

sm-sayedi · 2025-06-04T01:23:00Z

Thanks @chrisbobbe for the previous draft review! This is now ready for a complete review.

I have addressed Greg's review on #1530 and included those commits too. I will now start addressing your last review.

Note: The PR is giving the following CI/CD error, and I am not sure what it is about:

1 errors/warnings were listed in the baseline file (/home/runner/work/zulip-flutter/zulip-flutter/android/app/lint-baseline.xml) but not found in the project; perhaps they have been fixed?

Note: The baseline was created using a different target/variant than it was checked against.
Creation variant: lint
Current variant: lintVitalRelease

sm-sayedi · 2025-06-06T02:50:31Z

Was this changed because we decided to put the button on a separate line from the sender? Even so, maybe "Reveal message" is best -- I think it'll be clear enough.

@alya We had a discussion in #mobile-design > muted users @ 💬 and decided to use "Reveal message for muted sender", but I think it's longer and the newer version (Reveal message) is better.

alya · 2025-06-06T04:31:59Z

I suggested "Reveal message" above, so yes, that's fine.

sm-sayedi · 2025-06-06T05:48:30Z

Thanks @chrisbobbe for the previous reviews. I have addressed all comments but 1429 comment and 1429 comment from the previous review. For the first one, I left a comment below it. I will continue addressing these comments once I am back from the holiday.

Figma design: https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=6089-28385&t=28DdYiTs6fXWR9ua-0

The places are: - App bar title in DM narrow - DM recipient header

Conversations are excluded where all other recipients are muted.

This is solely for a better order.

Direct messages of those conversations are excluded where all of the other recipients are muted. Currently the applicable narrows are: - CombinedFeedNarrow - MentionsNarrow - StarredMessagesNarrow In the future, this will apply to the ReactionsNarrow from the Web app too, once we have it.

Fixes: zulip#296

sm-sayedi force-pushed the 296-respect-muted-users branch from c34b94b to d80442b Compare March 24, 2025 03:49

sm-sayedi force-pushed the 296-respect-muted-users branch 3 times, most recently from 86d0e66 to db3216f Compare May 2, 2025 19:01

sm-sayedi force-pushed the 296-respect-muted-users branch from db3216f to 17f2f6b Compare May 6, 2025 02:06

sm-sayedi force-pushed the 296-respect-muted-users branch 5 times, most recently from 8ab889f to cddcfcc Compare May 22, 2025 17:30

sm-sayedi commented May 22, 2025

View reviewed changes

sm-sayedi force-pushed the 296-respect-muted-users branch from cddcfcc to 3df45ad Compare May 23, 2025 09:50

chrisbobbe reviewed May 24, 2025

View reviewed changes

sm-sayedi mentioned this pull request May 24, 2025

Muted users prep #1530

Open

sm-sayedi force-pushed the 296-respect-muted-users branch from 3df45ad to c1a1982 Compare May 24, 2025 03:28

chrisbobbe reviewed Jun 1, 2025

View reviewed changes

sm-sayedi added 4 commits June 3, 2025 20:15

api: Add InitialSnapshot.mutedUsers

0fff6a6

api: Add muted_users event

3e4c18c

user: Add UserStore.mutedUsers with helper methods, updating with events

d7374c2

sm-sayedi force-pushed the 296-respect-muted-users branch 2 times, most recently from 9ca9390 to 55e46ff Compare June 4, 2025 01:03

sm-sayedi marked this pull request as ready for review June 4, 2025 01:05

sm-sayedi assigned sm-sayedi and chrisbobbe and unassigned sm-sayedi Jun 4, 2025

sm-sayedi requested a review from chrisbobbe June 4, 2025 01:24

sm-sayedi added the maintainer review PR ready for review by Zulip maintainers label Jun 4, 2025

chrisbobbe mentioned this pull request Jun 6, 2025

[WIP] message: Improve muted sender design. zulip/zulip#34794

Draft

12 tasks

sm-sayedi force-pushed the 296-respect-muted-users branch 2 times, most recently from 7eabd1e to 00cce74 Compare June 6, 2025 05:39

sm-sayedi added 10 commits June 6, 2025 10:48

msglist: Distinguish messages sent by muted users

da91fce

Figma design: https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=6089-28385&t=28DdYiTs6fXWR9ua-0

msglist: Cover remaining places for muted users in message list page

50af93e

The places are: - App bar title in DM narrow - DM recipient header

emoji: Distinguish muted users in reactions

51a15fe

poll: Distinguish muted users in polls

de6eff3

recent-dms: Distinguish muted users in recent DMs page

10a83e9

recent-dms: Exclude DM conversations with muted users

ad232ad

Conversations are excluded where all other recipients are muted.

msglist [nfc]: Place _allMessagesVisible right after _messageVisible

8626061

This is solely for a better order.

profile: Distinguish muted users in custom profile fields of type User

b98de85

autocomplete: Exclude muted users from user-mention autocomplete

50c6764

Fixes: zulip#296

sm-sayedi force-pushed the 296-respect-muted-users branch from 00cce74 to 50c6764 Compare June 6, 2025 06:19

		// Scale the icon proportionally to match the Figma design.
		size: size != null ? size! * 20 / 32 : null,

Name	Light	Dark
`listMenuItemBg`	`#cbcdd6`	`#2d303c`
`listMenuItemIcon`	`#9194a3`	`#767988`

Distinguish muted users in UI #1429

Are you sure you want to change the base?

Distinguish muted users in UI #1429

Uh oh!

Conversation

sm-sayedi commented Mar 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sm-sayedi commented May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrisbobbe commented May 23, 2025

Uh oh!

chrisbobbe left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrisbobbe May 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrisbobbe Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrisbobbe Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alya commented May 29, 2025

Uh oh!

chrisbobbe left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sm-sayedi commented Jun 4, 2025

Uh oh!

sm-sayedi commented Jun 6, 2025

Uh oh!

alya commented Jun 6, 2025

Uh oh!

sm-sayedi commented Jun 6, 2025

Uh oh!

Uh oh!

sm-sayedi commented Mar 21, 2025 •

edited

Loading

sm-sayedi commented May 22, 2025 •

edited

Loading

chrisbobbe May 24, 2025 •

edited

Loading

chrisbobbe Jun 6, 2025 •

edited

Loading

chrisbobbe Jun 6, 2025 •

edited

Loading

chrisbobbe left a comment •

edited

Loading