msglist: Support viewing who reacted to a message #1700

chrisbobbe · 2025-07-10T00:50:54Z

Fixes #740.

Followup:

View-reactions sheet doesn't update immediately when reactions change #1747

Notable changes from previous revision:

"See who reacted" button omitted in action sheet when no reactions
Emojis centered horizontally when few
Emojis scroll into view when tapped
Reasonable UI with VoiceOver (at least in my testing)
Wrote some basic tests

Screenshots

I've included some screenshots where there are

many emoji
many users

and in those, I set the scroll position such that you can see the shadow effect.

Light	Dark

Scroll-on-select animation:

gnprice · 2025-07-10T01:07:04Z

Thanks! I skimmed through this and I'm pretty confident it won't break any existing functionality. I also saw you demonstrate this running on your device, and it seemed to work well. So I plan to include this in today's upcoming release, without yet merging to main.

chrisbobbe · 2025-07-25T21:47:07Z

Thanks! This is now ready for review, and I've updated the issue description with changes since the draft.

gnprice · 2025-07-25T22:00:58Z

Thanks! Would you also post a few screenshots?

chrisbobbe · 2025-07-25T22:10:51Z

Sure! Done.

gnprice

Thanks!

Generally this looks good. Here's a full review except the tests.

gnprice · 2025-07-25T22:26:22Z

lib/widgets/emoji_reaction.dart

+          //    to the underlying Scrollable to remove an unwanted node
+          //    in accessibility focus traversal.
+          scrollDirection: Axis.horizontal,
+          physics: ClampingScrollPhysics(),


Interesting — why this instead of the default?

(I believe the default would be this on Android, but BouncingScrollPhysics on iOS.)

Ah yeah I think the default is fine actually :)

I was reading a tab-bar implementation (when doing the Semantics work for this PR) and I think it opted out of the "bouncing" behavior. But I'm not sure this is really a "tab bar" in the same sense as that code I was reading.

gnprice · 2025-07-25T22:38:14Z

lib/widgets/emoji_reaction.dart

+            messageId: widget.messageId,
+            reactionType: reactionType,
+            emojiCode: emojiCode,
+            onRequestSelect: (r) => _setSelection(r),


nit: tearoff

Suggested change

onRequestSelect: (r) => _setSelection(r),

onRequestSelect: _setSelection,

gnprice · 2025-07-25T22:43:22Z

lib/widgets/emoji_reaction.dart

+
+  /// Check that the given reaction still has votes;
+  /// if not, select a different one if possible or clear the selection.
+  void _reconcile() {


It looks like this always concludes with _setSelection. It might be a little clearer to read by making that explicit up front:

Suggested change

void _reconcile() {

void _reconcile() {

_setSelection(_findMatchingReaction());

}

Then _findMatchingReaction can directly return whenever it's found its answer.

gnprice · 2025-07-25T22:46:37Z

lib/widgets/emoji_reaction.dart

+    if (reactionType == null && widget.initialReactionType != null) {
+      assert(emojiCode == null);
+      assert(widget.initialEmojiCode != null);
+      reactionType = widget.initialReactionType!;
+      emojiCode = widget.initialEmojiCode!;


This doesn't depend on the store, does it? It looks like it doesn't use the context at all; so it could run as early as initState.

And conversely it doesn't sound like it'd be desirable for this to run repeatedly, or after a new store — these are the initial emoji type and code, after all.

gnprice · 2025-07-25T22:50:29Z

lib/widgets/emoji_reaction.dart

+    return SizedBox(
+      width: double.infinity,
+      child: Column(
+        mainAxisSize: MainAxisSize.min,


Would this be equivalent?

Suggested change

return SizedBox(

width: double.infinity,

child: Column(

mainAxisSize: MainAxisSize.min,

return Column(

mainAxisSize: MainAxisSize.min,

crossAxisAlignment: CrossAxisAlignment.stretch,

Ah no actually, and I think this is how it is in the released revision 🙂—it start-aligns the emoji items instead of center-aligning them.

Looks like I can get the desired behavior with CrossAxisAlignment.center instead of stretch, though.

Sorry, I don't quite understand the first sentence — can you spell out which version does what? (I.e. in "this is how" and "it start-aligns", what do "this" and "it" refer to?) Is the behavior in the release different from what was in this PR?

Ah sorry, yes that was confusing!

In 30.0.262, the items are start-aligned:

Here's code pasted from the 30.0.262 tag:

Widget build(BuildContext context) { // TODO could pull out this layout/appearance code, // focusing this widget only on state management return SizedBox( width: double.infinity, child: Column( crossAxisAlignment: CrossAxisAlignment.stretch, mainAxisSize: MainAxisSize.min, children: [ ViewReactionsHeader(widget.pageContext,

I want the items to be center-aligned, not start aligned. Column's default crossAxisAlignment is CrossAxisAlignment.center, so I can accomplish that with

return SizedBox( width: double.infinity, child: Column( mainAxisSize: MainAxisSize.min,

It turned out that the SizedBox isn't necessary, and I can spell out CrossAxisAlignment.center if that's helpful. So, as I've had in recent revisions of this PR:

return Column( mainAxisSize: MainAxisSize.min, crossAxisAlignment: CrossAxisAlignment.center,

which center-aligns the items.

Very helpful, thanks! OK, so an earlier version of this PR (as seen in v30.0.262) had "stretch" alignment. That makes the children wide, including the header; and then I think the Row in the header, with defaults MainAxisSize.max and MainAxisAlignment.start, ends up putting the items at the start.

The revised version looks good.

gnprice · 2025-07-25T23:55:30Z

lib/widgets/emoji_reaction.dart

+      (x) => x.reactionType == reactionType && x.emojiCode == emojiCode
+    )?.userIds.toList();
+
+    // (No filtering of muted or deactivated users.)


Suggested change

// (No filtering of muted or deactivated users.)

// (No filtering of muted or deactivated users.

// Muted users will be shown as muted.)

My first reaction to this comment was "is that right? seems like we shouldn't show muted users here." Then I remembered that that's probably handled at a different layer, and indeed it looks like it is.

gnprice · 2025-07-25T23:57:04Z

lib/widgets/emoji_reaction.dart

+    Widget result = InsetShadowBox(
+      top: 8, bottom: 8,
+      color: designVariables.bgContextMenu,
+      child: SizedBox(
+        height: 400, // TODO(design) tune
+        child: ListView.builder(
+          padding: EdgeInsets.symmetric(vertical: 8),


nit: move SizedBox outward, so the InsetShadowBox is right next to (in the source code) the padding that needs to match it

gnprice · 2025-07-25T23:59:46Z

lib/widgets/emoji_reaction.dart

+          itemBuilder: (context, index) =>
+            ViewReactionsUserItem(context, userId: userIds[index]))));


Same comment as I told Sayed last week 🙂 : #1706 (comment)

(on code that I guess was modeled in part on this PR, so no coincidence)

gnprice · 2025-07-26T00:03:50Z

lib/widgets/emoji_reaction.dart

+    Navigator.pop(pageContext);
+
+    Navigator.push(pageContext,
+      ProfilePage.buildRoute(context: pageContext, userId: userId));


I think the reason this works even though this pageContext isn't really a page context is that there's no await here.

The reason our action-sheet buttons often need a real page context is that they'll dismiss the action sheet, then do something that takes time like a network request, and then after that completes they need to use a context to do something with the result, or to show an error. So if the request takes longer than the few hundred ms of the dismiss animation, the action sheet's own context may be unmounted by that point.

For just synchronously acting on the navigation like this, the widget's own context is fine.

gnprice · 2025-07-26T00:06:16Z

lib/widgets/emoji_reaction.dart

+      onTap: _onPressed,
+      splashFactory: NoSplash.splashFactory,
+      overlayColor: WidgetStateColor.resolveWith((states) =>
+        states.any((e) => e == WidgetState.pressed)


Suggested change

states.any((e) => e == WidgetState.pressed)

states.contains(WidgetState.pressed)

Looks like it's a Set, so that should be equivalent (and potentially faster)

chrisbobbe · 2025-08-01T00:20:45Z

Thanks for the review! Revision pushed. I noticed on reaction chips that the tooltip-on-long-press was sometimes winning out over the show-view-reactions-sheet, so I added a commit to get rid of the tooltip, with a test change for some tests that had been relying on it.

I also added a tweak to the scroll-into-view logic for the horizontal list of emojis, as a separate commit on top.

chrisbobbe · 2025-08-01T00:28:21Z

And I've just updated the screenshots.

gnprice

Thanks for the revision! Just a few comments.

gnprice · 2025-08-01T01:45:58Z

lib/widgets/emoji_reaction.dart

+    if (MediaQuery.accessibleNavigationOf(context)) {
+      // Avoid a _voterNames call with potentially many users,
+      // except in this case where a computation lag would be very small
+      // compared to the time saved in accessing the information.
+      result = Semantics(
+        label: _semanticsLabelWithVoterNames(store, zulipLocalizations),


Hmm. I agree the computation time might not be a big deal here. But this feels like it's making the UI more complicated to think about — if the user is using TalkBack or VoiceOver, it's presenting different information that isn't present in the UI we regularly use ourselves. I'd prefer to avoid that complication.

Can this instead just present the same information that's there in the main UI? It's true that getting the list of people who reacted is then an extra step or two for people using a screen-reader; but it's an extra step or two for everyone else, too, so that doesn't seem terrible.

Here's what the Flutter doc on the relevant MediaQueryData field says:

/// Whether the user is using an accessibility service like TalkBack or /// VoiceOver to interact with the application. /// /// When this setting is true, features such as timeouts should be disabled or /// have minimum durations increased.

So this conditional seems rather afield from that.

(Or for now just present the same information that had been in the tooltip, namely the emoji name.)

gnprice · 2025-08-01T01:54:36Z

lib/widgets/emoji_reaction.dart

+    return SizedBox(
+      width: double.infinity,
+      child: Column(
+        mainAxisSize: MainAxisSize.min,


Sorry, I don't quite understand the first sentence — can you spell out which version does what? (I.e. in "this is how" and "it start-aligns", what do "this" and "it" refer to?) Is the behavior in the release different from what was in this PR?

gnprice · 2025-08-01T01:57:41Z

lib/widgets/emoji_reaction.dart

+  @override
+  void initState() {
+    super.initState();
+    if (reactionType == null && widget.initialReactionType != null) {


The reactionType == null condition is always true now that this is in initState, right?

gnprice · 2025-08-01T02:07:27Z

lib/widgets/emoji_reaction.dart

+  /// When auto-scrolling an emoji into view,
+  /// this is where the scroll position will land
+  /// (the min- and max- scroll extent lerped to this value).
+  double _emojiItemPosition(int index, int aggregatedLength) {


lerped "at"?

Or some other/further rewording. I'd read "lerped to X" as meaning that X was the second argument of a lerp method — conceptually the arguments are start, end, and time.

gnprice · 2025-08-01T02:10:16Z

lib/widgets/emoji_reaction.dart

+    final destination = lerpDouble(
+      scrollPosition.minScrollExtent,
+      scrollPosition.maxScrollExtent,
+      position);
+    if (destination == null) return; // TODO(log)


This condition is impossible, right? (From the definition of lerpDouble.) So just use !.

This fixes the two inconsistencies flagged in discussion: https://chat.zulip.org/#narrow/channel/530-mobile-design/topic/bottom.20sheet.20.22Cancel.22.2F.22Close.22.20button/near/2216116 > I think it's reasonable to have both labels, but I think we should > choose them differently than now: > > - "Cancel" when the sheet is about doing an action: [etc.] > > - "Close" when the sheet just presents information or nav options: > [etc.]

See Vlad's SVG on CZO: https://chat.zulip.org/#narrow/channel/530-mobile-design/topic/View.20Reactions.20ModalBottomSheet/near/2025350

…s test So we can add another test that uses it.

We'll use this for a semantics label, coming up.

In a later commit in this series, we'll replace the long-press action with showing a "view-reactions" sheet. We won't want something else that's triggered on long-press, like this tooltip, and the tooltip was sometimes winning the gesture-detection in my testing at that later commit. Remove the tooltip, replacing it with a semantics label, which tests that were relying on the tooltip can use instead.

chrisbobbe · 2025-08-01T19:17:23Z

Thanks! Revision pushed.

chrisbobbe · 2025-08-01T20:13:36Z

lib/widgets/emoji_reaction.dart

+    }
+
+    Widget result = SizedBox(
+      height: 400,


Oh oops, I meant to leave a TODO(design) tune here (I think I had it in an earlier revision)—will put it back in my next revision

gnprice · 2025-08-01T23:25:26Z

Thanks! All looks good to me. Please go ahead and merge after that comment tweak.

I experimented with using Semantics to help write human-centered tests, and I ended up adding some configuration that actually seemed to make a reasonable experience in the UI, at least in my testing with VoiceOver. Fixes zulip#740.

For motivation, see the comment on _scrollIntoView.

chrisbobbe · 2025-08-02T00:10:44Z

Done, thanks!

chrisbobbe requested a review from gnprice July 10, 2025 00:50

chrisbobbe assigned gnprice Jul 10, 2025

chrisbobbe added the integration review Added by maintainers when PR may be ready for integration label Jul 10, 2025

chrisbobbe mentioned this pull request Jul 10, 2025

Add a "(you)" indicator in direct messages list #1320

Open

gnprice mentioned this pull request Jul 10, 2025

See who left an emoji reaction #740

Closed

sm-sayedi mentioned this pull request Jul 15, 2025

Show read receipts #1706

Open

chrisbobbe force-pushed the pr-see-who-reacted branch from 27dd265 to d0f7d15 Compare July 25, 2025 21:44

chrisbobbe marked this pull request as ready for review July 25, 2025 21:46

chrisbobbe force-pushed the pr-see-who-reacted branch from d0f7d15 to 399cd6a Compare July 25, 2025 21:47

chrisbobbe force-pushed the pr-see-who-reacted branch from 399cd6a to e653144 Compare July 25, 2025 22:04

gnprice reviewed Jul 26, 2025

View reviewed changes

chrisbobbe force-pushed the pr-see-who-reacted branch from e653144 to 45ad6ab Compare August 1, 2025 00:18

gnprice reviewed Aug 1, 2025

View reviewed changes

chrisbobbe added 9 commits August 1, 2025 10:54

icons: Add see_who_reacted, from Vlad on CZO

f69eac9

See Vlad's SVG on CZO: https://chat.zulip.org/#narrow/channel/530-mobile-design/topic/View.20Reactions.20ModalBottomSheet/near/2025350

action_sheet: Implement BottomSheetHeaderPlainText, following Figma

b5c955b

inset_shadow test [nfc]: Pull PaintPatternPredicate helper outside it…

538e5ae

…s test So we can add another test that uses it.

inset_shadow: Implement start/end shadows, not just top/bottom

6a429b1

emoji_reaction test [nfc]: Pull out some data for other tests to use

1556946

emoji_reaction: Put "You" first in ReactionChip label; pull out helper

025b0ce

We'll use this for a semantics label, coming up.

emoji_reaction: Add labeled Semantics container node for reactions list

41e3d57

chrisbobbe force-pushed the pr-see-who-reacted branch from 45ad6ab to 1d12c74 Compare August 1, 2025 19:17

chrisbobbe commented Aug 1, 2025

View reviewed changes

chrisbobbe added 2 commits August 1, 2025 17:05

msglist: Support viewing who reacted to a message

e2c10ae

I experimented with using Semantics to help write human-centered tests, and I ended up adding some configuration that actually seemed to make a reasonable experience in the UI, at least in my testing with VoiceOver. Fixes zulip#740.

emoji_reaction: Refine scroll-into-view logic

98b94bd

For motivation, see the comment on _scrollIntoView.

chrisbobbe force-pushed the pr-see-who-reacted branch from 1d12c74 to 98b94bd Compare August 2, 2025 00:10

chrisbobbe merged commit 98b94bd into zulip:main Aug 2, 2025
1 check failed

chrisbobbe deleted the pr-see-who-reacted branch August 2, 2025 00:10

	onRequestSelect: (r) => _setSelection(r),
	onRequestSelect: _setSelection,

	// (No filtering of muted or deactivated users.)
	// (No filtering of muted or deactivated users.
	// Muted users will be shown as muted.)

		itemBuilder: (context, index) =>
		ViewReactionsUserItem(context, userId: userIds[index]))));

	states.any((e) => e == WidgetState.pressed)
	states.contains(WidgetState.pressed)

msglist: Support viewing who reacted to a message #1700

msglist: Support viewing who reacted to a message #1700

Uh oh!

Conversation

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

Uh oh!

Screenshots

Uh oh!

gnprice commented Jul 10, 2025

Uh oh!

chrisbobbe commented Jul 25, 2025

Uh oh!

gnprice commented Jul 25, 2025

Uh oh!

chrisbobbe commented Jul 25, 2025

Uh oh!

gnprice 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!

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 commented Aug 1, 2025

Uh oh!

chrisbobbe commented Aug 1, 2025

Uh oh!

gnprice 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!

chrisbobbe commented Aug 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gnprice commented Aug 1, 2025

Uh oh!

Uh oh!

chrisbobbe commented Aug 2, 2025

Uh oh!

Uh oh!

chrisbobbe commented Jul 10, 2025 •

edited

Loading