Show user status in UI #1702

sm-sayedi · 2025-07-10T01:31:44Z

The remaining half of #1629. For related images, please see #1629 description.

Fixes: #197

gnprice · 2025-07-10T21:59:02Z

Copying the review status from #1629 (per #1629 (review)): I've read the first commit except for its tests:
463b938 msglist: Show user status emoji

and the comments I had there have been resolved. Remaining to review are those tests, and the other 4 commits:
14093b2 recent-dms: Show user status emoji in recent DMs page
646f9d9 new-dm: Show user status emoji
846261a autocomplete: Show user status emoji in user-mention autocomplete
e9f682e profile: Show user status

gnprice

Thanks again for building this! Comments below.

I've read through the whole of the first commit:
463b938 msglist: Show user status emoji

and the non-test changes in the other commits:
14093b2 recent-dms: Show user status emoji in recent DMs page
646f9d9 new-dm: Show user status emoji
846261a autocomplete: Show user status emoji in user-mention autocomplete
e9f682e profile: Show user status

For this round, I skipped the tests in the later commits because I think a number of my comments on the first commit's tests will apply to those too. So please go ahead and revise the later tests too where applicable.

gnprice · 2025-07-16T20:41:50Z

test/widgets/message_list_test.dart

+/// Finder for [UserStatusEmoji] widget.
+///
+/// Use [type] to specify the exact emoji child widget. It can be either
+/// [UnicodeEmojiWidget] or [ImageEmojiWidget].
+Finder findStatusEmoji(Type type) {
+  assert(type == UnicodeEmojiWidget || type == ImageEmojiWidget);
+  return find.ancestor(
+    of: find.byType(type),
+    matching: find.byType(UserStatusEmoji));


This seems like it's clearer if just inlined at its call sites.

The implementation (minus the assert, which becomes unnecessary) isn't much longer than the call; and it's more transparent about what it's doing. I also don't feel like this is particularly encapsulating any knowledge of the details of how the UserStatusEmoji widget works.

Also, after doing that: how about just find.byType(UserStatusEmoji)? It's not clear to me what's gained by adding the condition that the widget have a UnicodeEmojiWidget descendant, or an ImageEmojiWidget descendant.

Also, after doing that: how about just find.byType(UserStatusEmoji)?

Copying #1629 (comment) here: 🙂

As we discussed in this week’s check-in call, UserStatusEmoji for many cases can contain only SizedBox.shrink(), including when there’s no status set for a user. So only using find.byType(UserStatusEmoji) will pass the tests even when we don’t pass status for a user.

(continued in #1702 (comment) below)

gnprice · 2025-07-16T20:46:07Z

test/widgets/message_list_test.dart

+void checkUserStatusEmoji(Finder emojiFinder, {required bool isAnimated}) {
+  check((emojiFinder
+    .evaluate().first.widget as UserStatusEmoji).neverAnimate).equals(!isAnimated);


This also feels like it'd be clearer inlined. The actual check is all about neverAnimate, but the name doesn't sound like that — it sounds like it's going to be doing some other, more general, check.

gnprice · 2025-07-16T20:47:42Z

test/widgets/message_list_test.dart

+  check((emojiFinder
+    .evaluate().first.widget as UserStatusEmoji).neverAnimate).equals(!isAnimated);


Instead of finder.evaluate(), use tester explicitly:

Suggested change

check((emojiFinder

.evaluate().first.widget as UserStatusEmoji).neverAnimate).equals(!isAnimated);

check(tester.firstWidget<UserStatusEmoji>(emojiFinder).neverAnimate)

.equals(!isAnimated);

That way it's conceptually clearer what's going on. (The implementation of finder.evaluate will end up using the same WidgetTester instance anyway, getting hold of it behind the scenes via a singleton.)

The main motivation for not using tester was to minimize the number of params passed to the helper methods (checkStatusEmoji and others in the next commits). Now that it helps in making the tests clearer, so going to use that in the new revision.🙂

gnprice · 2025-07-16T20:49:24Z

test/widgets/message_list_test.dart

@@ -91,6 +110,7 @@ void main() {
    if (mutedUserIds != null) {
      await store.setMutedUsers(mutedUserIds);
    }
+    await store.changeUserStatuses(userStatuses ?? []);


How about having the individual test cases do this? That way we avoid adding yet another feature to this shared helper. (It probably should have fewer features already — that'd help make fewer things for the reader of each test case to potentially have to think about.)

gnprice · 2025-07-16T20:53:58Z

test/widgets/message_list_test.dart

+          userStatuses: [
+            (
+              user1.userId,
+              UserStatusChange(
+                text: OptionSome('Busy'),


Hmm, these tuples are a bit of a pain to read.

How about making changeUserStatuses instead take a Map? That seems semantically appropriate, as there's no reason to have the same user ID more than once in the same call. Then:

Suggested change

userStatuses: [

(

user1.userId,

UserStatusChange(

text: OptionSome('Busy'),

userStatuses: {

user1.userId: UserStatusChange(

text: OptionSome('Busy'),

gnprice · 2025-07-16T21:22:08Z

lib/widgets/autocomplete.dart

+              Flexible(child: labelWidget),
+              if (option case UserMentionAutocompleteResult(:var userId))
+                UserStatusEmoji(userId: userId, size: 18,
+                  padding: const EdgeInsetsDirectional.only(start: 5.0))]),


nit: similarly:

Suggested change

padding: const EdgeInsetsDirectional.only(start: 5.0))]),

padding: const EdgeInsetsDirectional.only(start: 5.0)),

]),

gnprice · 2025-07-16T21:25:44Z

lib/widgets/autocomplete.dart

          children: [
-            labelWidget,
+            Row(children: [
+              Flexible(child: labelWidget),
+              if (option case UserMentionAutocompleteResult(:var userId))
+                UserStatusEmoji(userId: userId, size: 18,
+                  padding: const EdgeInsetsDirectional.only(start: 5.0))]),
            if (sublabelWidget != null) sublabelWidget,
          ])),


I think this new logic is best included as part of labelWidget. Conceptually it's closely tied to the user's name, which is part of the label.

Probably in fact the cleanest home for this is in the switch (option) above, which is already the place where we inspect the details of option.

gnprice · 2025-07-16T21:28:37Z

lib/widgets/profile.dart

@@ -73,17 +75,28 @@ class ProfilePage extends StatelessWidget {
          ),
          // TODO write a test where the user is muted; check this and avatar
          TextSpan(text: store.userDisplayName(userId, replaceIfMuted: false)),
+          UserStatusEmoji.asWidgetSpan(
+            userId: userId,
+            fontSize: 20,


nit: this says fontSize: 20 but the presence circle above says fontSize: nameStyle.fontSize!; should say the same thing both places, since the intent is for them to be the same

gnprice · 2025-07-16T21:29:57Z

lib/widgets/profile.dart

@@ -47,6 +48,7 @@ class ProfilePage extends StatelessWidget {
    if (user == null) {
      return const _ProfileErrorPage();
    }
+    final userStatus = store.getUserStatus(userId);


nit: put this next to displayEmail; conceptually they're here for the very same reason

gnprice · 2025-07-16T21:32:35Z

lib/widgets/profile.dart

+            color: DesignVariables.of(context).userStatusText)),
+
      if (displayEmail != null)


Is this blank line intended?

The items just above here feel to me closely related to the items just below, and in particular just as closely related as other items that are grouped next to each other.

sm-sayedi · 2025-07-17T18:26:42Z

Thanks @gnprice for the detailed review. Revision pushed, PTAL.

Note: CI is failing with the following issue:

Run flutter pub get
Resolving dependencies...
The current Flutter SDK version is 0.0.0-unknown.

Because zulip requires Flutter SDK version >=3.33.0-1.0.pre.832, version solving failed.


You can try the following suggestion to make the pubspec resolve:
* Try using the Flutter SDK version: 3.35.0-0.0.pre. 
Failed to update packages.
Error: Process completed with exit code 1.

I tried pushing several times, but it didn't solve the problem.

gnprice · 2025-07-17T22:44:59Z

Yeah, that CI failure is unrelated. Filed as #1710, and I'll fix it.

gnprice

Thanks for the revision! Just a handful of comments this time. I've read the same portions of the branch as last round, plus the two small new commits.

gnprice · 2025-07-18T04:06:55Z

test/widgets/message_list_test.dart

+        await store.changeUserStatuses({
+          user.userId: UserStatusChange(
+            text: OptionSome('Busy'),


nit: can be a bit simpler and more compact by calling changeUserStatus directly:

Suggested change

await store.changeUserStatuses({

user.userId: UserStatusChange(

text: OptionSome('Busy'),

await store.changeUserStatus(user.userId, UserStatusChange(

text: OptionSome('Busy'),

Also nice is that that corresponds more directly to what happens in the real server API: each user's status comes in a separate UserStatusEvent.

gnprice · 2025-07-18T04:09:24Z

test/widgets/message_list_test.dart

+        await setupMessageListPage(tester,
+          users: [user],
+          messages: [eg.streamMessage(sender: user)],
+        );


nit: can compact a bit vertically:

Suggested change

await setupMessageListPage(tester,

users: [user],

messages: [eg.streamMessage(sender: user)],

);

await setupMessageListPage(tester,

users: [user], messages: [eg.streamMessage(sender: user)]);

Making each test case more compact is helpful for the reader scanning through a given test case to fully understand what it's doing, and especially for scanning through several neighboring test cases to compare them and to think about what situations are covered and what situations there might be that aren't yet.

gnprice · 2025-07-18T04:15:51Z

test/widgets/message_list_test.dart

+        });
+        await tester.pump();
+
+        checkStatusEmoji(tester, type: ImageEmojiWidget, isPresent: true);


It's kind of puzzling to me that this isn't giving an error, actually: if there's an image emoji here, that should be a RealmContentNetworkImage, which should mean the widget tries to load an image from the network. And I'd expect that to throw an error, given that this test case hasn't set debugNetworkImageHttpClientProvider (e.g. by calling prepareBoringImageHttpClient).

Would you try to get to the bottom of that? I wonder if perhaps this widget tree isn't getting fully built in one frame, and another tester.pump is needed in order to fully exercise the code.

The first problem is that it needs another tester.pump, but even with that, it will not throw an error because we have ImageEmojiWidget.errorBuilder set. Nevertheless, added prepareBoringImageHttpClient.

Hmm, I see.

How did you determine that it needs another tester.pump — what's missing after the first pump?

Examining the code again, if ImageEmojiWidget.errorBuilder is not provided, there is no need for the second pump. Only with the first pump will the code throw the error.
The last time that I concluded that it needs two pumps is because I used a print statement inside ImageEmojiWidget.errorBuilder with the assumption that if there is an error, then errorBuilder is called. But it is triggered after a setState, which requires the second pump in the test code to see if it is called.

Cool; thanks for the explanation!

gnprice · 2025-07-18T04:25:13Z

test/widgets/message_list_test.dart

+        });
+        await tester.pump();
+
+        checkStatusEmoji(tester, type: UnicodeEmojiWidget, isPresent: true);


Instead of find.byType(UnicodeEmojiWidget), how about something like find.text("\u{1f6e0}")? (Continuing from #1702 (comment) .)

That's more nicely end-to-end — it expresses what we're looking for in terms of what the user sees, rather than the way we've organized our code. In this case it makes it a bit more specific; it also means that if we refactor how those widgets work, these tests wouldn't need to change. (Except insofar as we changed how the UI actually looks to the user in ways this is checking for, which is a good reason to need to change it.)

Then I think that opens up a further refactor that would make these a bit more transparent:

Suggested change

checkStatusEmoji(tester, type: UnicodeEmojiWidget, isPresent: true);

checkFindsStatusEmoji(tester, find.text('\u{1f6e0}'));

The isPresent: false call sites could become like:

check(find.text('\u{1f6e0}')).findsNothing();

…. But actually, looking at them, the test data in those test cases doesn't supply any emoji in the first place. I think it's fine to not have any such check in that case, then — instead we can rely on an assumption that our code isn't going to invent out of whole cloth an emoji to display as the user's status emoji.

gnprice · 2025-07-18T04:31:52Z

test/widgets/message_list_test.dart

+        final senderRowFinder = find.ancestor(of: nameFinder,
+          matching: find.ancestor(of: statusEmojiFinder,
+            matching: find.byType(Row)));
+        isPresent
+          ? check(senderRowFinder).findsAny()


Sure, that works.

It does introduce some degree of dependence on the internals of how we've organized our widgets (the existence of a SenderRow widget class, and the fact that it should contain the status emoji). But I think the concept of a "sender row" is a pretty stable aspect of our UI, so that the only way that assumption is likely to break is if we're changing the real user-visible UI in a way that alters the user-facing fact that the sender's status emoji belongs on a row together with their name etc.

gnprice · 2025-07-18T04:36:50Z

lib/widgets/recent_dm_conversations.dart

+        title = TextSpan(children: [
+          TextSpan(text: store.selfUser.fullName),


nit: can simplify these a bit by using both text and children:

Suggested change

title = TextSpan(children: [

TextSpan(text: store.selfUser.fullName),

title = TextSpan(text: store.selfUser.fullName, children: [

(See the docs for those two TextSpan fields.)

Looking at the TextSpan implementation, I think that saves a small amount of work by eliminating that indirection. There's potentially a lot of these on the screen, so that savings is potentially useful too.

gnprice · 2025-07-18T04:42:43Z

lib/widgets/autocomplete.dart

        label = store.userDisplayName(userId);
+        emoji = UserStatusEmoji(userId: userId, size: 18,
+          padding: const EdgeInsetsDirectional.only(start: 5.0));
        sublabel = store.userDisplayEmail(userId);
      case WildcardMentionAutocompleteResult(:var wildcardOption):
        avatar = SizedBox.square(dimension: 36,
          child: const Icon(ZulipIcons.three_person, size: 24));
+        emoji = null;
        label = wildcardOption.canonicalString;


nit: order label vs. emoji consistently

(probably label then emoji, to correspond to how they're displayed)

sm-sayedi · 2025-07-18T18:12:41Z

Thanks for the review. New revision pushed.

sm-sayedi · 2025-07-18T18:15:42Z

test/widgets/recent_dm_conversations_test.dart

+                emojiCode: '1f6e0', reactionType: ReactionType.unicodeEmoji))));
+            await tester.pump();
+
+            checkFindsStatusEmoji(tester, find.text('\u{1f6e0}'));


For this commit and the following ones, should we make find.text('\u{1f6e0}') an implementation detail of checkFindsStatusEmoji as it stays the same?

Hmm, I thought I replied to this in the last round, but I don't see the reply.

It's an important part of how this test works that the emoji it's looking for here is the same one as the emoji the user has as their status emoji. So this line and the emojiCode: '1f6e0' a few lines above need to agree.

If this were moved inside checkFindsStatusEmoji, then someone reading that function would see a mysterious \u{1f6e0} and have to wonder why that particular code point was the one to check for; and someone reading this test case would be unaware that the checkFindsStatusEmoji function it's calling has a secret dependence on this detail of how the test set up its data. So both sides of that division would become impossible for a reader to properly understand without going and reading the other side too.

In short, it wouldn't really be an implementation detail — it'd be an essential part of the interface that checkFindsStatusEmoji presents to its callers.

If on the other hand we had a helper function that included both the work of checkFindsStatusEmoji and the setup step above, then it'd make sense for that helper function's source to specify which emoji to use, because that really would be an implementation detail.

There are a few ways one could organize the code so as to still ensure that both the test cases and the helpers are readable and understandable without having to go search for related code and look for hidden dependencies. But I think the organization in the current revision works well.

Got it, thanks for the explanation.

gnprice

Thanks! Comments below on the changes.

gnprice · 2025-07-18T19:22:49Z

lib/widgets/new_dm_sheet.dart

+                TextSpan(children: [
+                  TextSpan(text: store.userDisplayName(userId)),


same as #1702 (comment)

gnprice · 2025-07-18T19:26:36Z

test/widgets/message_list_test.dart

+        checkFindsStatusEmoji(tester, find.text('\u{1f6e0}'));
+        check(find.descendant(of: find.byType(SenderRow),
+          matching: find.text('Busy'))).findsNothing();


This test is a bit stronger if the "finds nothing" check isn't limited by SenderRow:

Suggested change

checkFindsStatusEmoji(tester, find.text('\u{1f6e0}'));

check(find.descendant(of: find.byType(SenderRow),

matching: find.text('Busy'))).findsNothing();

checkFindsStatusEmoji(tester, find.text('\u{1f6e0}'));

check(find.text('Busy')).findsNothing();

With the SenderRow restriction, the reader has to wonder if perhaps the status text is getting shown after all, and just doesn't happen to be within a widget called SenderRow. (Perhaps something changed in the organization of the UI code.)

This is a bit different from the situation at #1702 (comment) (where introducing SenderRow was OK), because the check has the opposite polarity. In that test, adding a SenderRow condition makes the check more demanding — so if the code gets reorganized in a way that breaks the test's implicit assumptions about how it's organized, then the test will fail and we'll know we need to update it. But here, adding SenderRow makes it less demanding — so in that situation the check wouldn't fail, but instead would become vacuous, less able to fail when it should.

gnprice · 2025-07-18T19:32:53Z

test/widgets/message_list_test.dart

+          text: OptionSome('Coding'),
+          emoji: OptionSome(StatusEmoji(emojiName: 'zulip',
+            emojiCode: 'zulip', reactionType: ReactionType.zulipExtraEmoji))));
+        await tester.pumpAndSettle();


Best to avoid pumpAndSettle: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#avoid-using-pumpandsettle

Can this be two pumps? Better to be explicit that way.

gnprice · 2025-07-18T19:36:53Z

test/widgets/message_list_test.dart

+        });
+        await tester.pump();
+
+        checkStatusEmoji(tester, type: ImageEmojiWidget, isPresent: true);


Hmm, I see.

How did you determine that it needs another tester.pump — what's missing after the first pump?

gnprice · 2025-07-18T19:42:56Z

test/widgets/message_list_test.dart

+        final senderRowFinder = find.ancestor(of: statusEmojiFinder,
+          matching: find.byType(SenderRow));
+        check(senderRowFinder).findsOne();


nit: I think this would be just as clear if inlined, and a bit shorter. It's saying the status emoji has a SenderRow as an ancestor.

Then also can drop the blank line above, and join this function's whole body in one stanza.

gnprice · 2025-07-18T19:43:55Z

test/widgets/message_list_test.dart

+        check(statusEmojiFinder).findsOne();
+        check(tester.firstWidget<UserStatusEmoji>(statusEmojiFinder)


nit: since we're expecting this to find just one widget anyway, can simplify firstWidget to widget:

Suggested change

check(statusEmojiFinder).findsOne();

check(tester.firstWidget<UserStatusEmoji>(statusEmojiFinder)

check(statusEmojiFinder).findsOne();

check(tester.widget<UserStatusEmoji>(statusEmojiFinder)

sm-sayedi

Thank @gnprice for the review. New changes pushed.

sm-sayedi · 2025-07-19T10:35:15Z

test/widgets/recent_dm_conversations_test.dart

+            await tester.pump();
+
+            checkFindsStatusEmoji(tester, find.text('\u{1f6e0}'));
+            check(find.textContaining('Busy')).findsNothing();


In places where status emoji is used as a span, I used find.textContaining instead of find.text, so if status text is shown in a text span, these tests can detect it.

Cool — that's good for these negative checks (.findsNothing()), as it makes them stronger.

sm-sayedi · 2025-07-19T10:41:31Z

test/widgets/new_dm_sheet_test.dart

+      checkFindsTileStatusEmoji(tester, user, find.text('\u{1f6e0}'));
+      check(find.descendant(of: findUserTile(user),
+        matching: find.textContaining('Busy'))).findsNothing();
+      check(findUserChip(user)).findsOne();
+      checkFindsChipStatusEmoji(tester, user, find.text('\u{1f6e0}'));
+      check(find.descendant(of: findUserChip(user),
+        matching: find.text('Busy'))).findsNothing();


I still kept this check for the status texts the same as before (didn't remove find.descendant), as there could be status texts in two places on the same page (one for the user tile, another for the user chip).

Hmm. But these are still both negative checks — so it's still true that there shouldn't be "Busy" anywhere at all, right?

And saying "no 'Busy' anywhere" is a stronger requirement than "no 'Busy' in place A and no 'Busy' in place B". So I think all the same logic in #1702 (comment) still applies.

gnprice

Thanks for the revision! I've now read through the whole thing.

Comments below on a few things that came up only in those remaining tests. I've also just pushed a couple of additional commits, as described in one of those below comments:
9aa3c6293 test: Add find.text analogue with includePlaceholders option
4eca2897e (squash) Demo using the new findText and includePlaceholders

The first should get reordered to earlier in the branch, before the point it's needed; the second does part of the conversion to use the new finder, which you can squash into the appropriate commits before doing the rest.

gnprice · 2025-07-21T23:09:06Z

test/widgets/recent_dm_conversations_test.dart

+                emojiCode: '1f6e0', reactionType: ReactionType.unicodeEmoji))));
+            await tester.pump();
+
+            checkFindsStatusEmoji(tester, find.text('\u{1f6e0}'));


Hmm, I thought I replied to this in the last round, but I don't see the reply.

It's an important part of how this test works that the emoji it's looking for here is the same one as the emoji the user has as their status emoji. So this line and the emojiCode: '1f6e0' a few lines above need to agree.

If this were moved inside checkFindsStatusEmoji, then someone reading that function would see a mysterious \u{1f6e0} and have to wonder why that particular code point was the one to check for; and someone reading this test case would be unaware that the checkFindsStatusEmoji function it's calling has a secret dependence on this detail of how the test set up its data. So both sides of that division would become impossible for a reader to properly understand without going and reading the other side too.

In short, it wouldn't really be an implementation detail — it'd be an essential part of the interface that checkFindsStatusEmoji presents to its callers.

If on the other hand we had a helper function that included both the work of checkFindsStatusEmoji and the setup step above, then it'd make sense for that helper function's source to specify which emoji to use, because that really would be an implementation detail.

There are a few ways one could organize the code so as to still ensure that both the test cases and the helpers are readable and understandable without having to go search for related code and look for hidden dependencies. But I think the organization in the current revision works well.

gnprice · 2025-07-21T23:51:34Z

test/widgets/recent_dm_conversations_test.dart

-          matching: find.text(expectedText),
+          matching: find.textContaining(expectedText),


Hmm, it's unfortunate to make all the existing tests here less specific. We do want the title that the user sees to be the title we intend — and not, for example, the intended title plus some whitespace or other added text.

I'm guessing that the reason you made this less specific is because the title now has a WidgetSpan in it for the status emoji, and that doesn't match. In that case, it'd be good to keep the check so that it allows that part to differ, but no more.

It looks like Flutter upstream already has most of the work done to support ignoring WidgetSpans in these matches — it's just missing the last step. I just drafted up an implementation of that last step, and I'll push it as an added commit to this branch. (I'll also see about sending the same functionality as a PR upstream.) Then this line can say:

matching: findText(expectedText, includePlaceholders: false),

And after the functionality is upstream, it can be:

matching: find.text(expectedText, includePlaceholders: false),

gnprice · 2025-07-21T23:53:21Z

test/widgets/recent_dm_conversations_test.dart

+            await tester.pump();
+
+            checkFindsStatusEmoji(tester, find.text('\u{1f6e0}'));
+            check(find.textContaining('Busy')).findsNothing();


Cool — that's good for these negative checks (.findsNothing()), as it makes them stronger.

gnprice · 2025-07-21T23:56:27Z

test/widgets/new_dm_sheet_test.dart

+      checkFindsTileStatusEmoji(tester, user, find.text('\u{1f6e0}'));
+      check(find.descendant(of: findUserTile(user),
+        matching: find.textContaining('Busy'))).findsNothing();
+      check(findUserChip(user)).findsOne();
+      checkFindsChipStatusEmoji(tester, user, find.text('\u{1f6e0}'));
+      check(find.descendant(of: findUserChip(user),
+        matching: find.text('Busy'))).findsNothing();


Hmm. But these are still both negative checks — so it's still true that there shouldn't be "Busy" anywhere at all, right?

And saying "no 'Busy' anywhere" is a stronger requirement than "no 'Busy' in place A and no 'Busy' in place B". So I think all the same logic in #1702 (comment) still applies.

gnprice · 2025-07-22T00:03:28Z

test/widgets/profile_test.dart

+    await store.changeUserStatus(user.userId, UserStatusChange(
+      text: OptionSome('Busy'),
+      emoji: OptionSome(StatusEmoji(emojiName: 'working_on_it',
+        emojiCode: '1f6e0', reactionType: ReactionType.unicodeEmoji))));
+    await tester.pump();

    check(because: 'find user avatar', find.byType(Avatar).evaluate()).length.equals(1);
    check(because: 'find user name', find.text('test user').evaluate()).isNotEmpty();
+    final statusEmojiFinder = find.ancestor(of: find.text('\u{1f6e0}'),
+      matching: find.byType(UserStatusEmoji));
+    check(because: 'find user status emoji', statusEmojiFinder).findsOne();
+    check(tester.widget<UserStatusEmoji>(statusEmojiFinder)
+      .neverAnimate).isFalse();
+    check(because: 'find user status text', find.text('Busy')).findsOne();


Let's put these checks into their own new test case, and leave this one as it is.

That will make both sets of test steps easier to understand than when they're combined into one does-everything test scenario like this.

That will also make this test a bit stronger: the existing test case will effectively check that if there is no user status, that doesn't cause this page to crash (e.g. because of a misplaced !, as in userStatus.text!).

The bulk of this code is copied verbatim from the implementation of `find.text`, in `package:flutter_test/src/finders.dart`. The new logic is just the includePlaceholders flag, and passing it down to where InlineSpan.toPlainText gets called. The latter already has a corresponding flag, which does the rest.

Status emojis are only shown for self-1:1 and 1:1 conversation items. They're ignored for group conversations as that's what the Web does.

Fixes: zulip#197

sm-sayedi · 2025-07-22T14:47:26Z

Thanks for the review @gnprice. New revision pushed; PTAL.

This was referenced Jul 10, 2025

Set user status #1701

Draft

Show user status #1699

Closed

gnprice changed the title ~~Track user status - Part 2~~ Show user status in UI Jul 10, 2025

gnprice mentioned this pull request Jul 10, 2025

Track user status #197

Open

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

gnprice reviewed Jul 16, 2025

View reviewed changes

sm-sayedi force-pushed the 197-P2 branch 3 times, most recently from eccaa7a to 686130f Compare July 17, 2025 18:22

sm-sayedi requested a review from gnprice July 17, 2025 18:26

sm-sayedi force-pushed the 197-P2 branch from 686130f to cedb204 Compare July 17, 2025 18:46

gnprice mentioned this pull request Jul 17, 2025

CI broken by lack of recent tags in Flutter main/master branch #1710

Closed

gnprice reviewed Jul 18, 2025

View reviewed changes

sm-sayedi force-pushed the 197-P2 branch 2 times, most recently from b14ee65 to cd4a1a6 Compare July 18, 2025 18:09

sm-sayedi commented Jul 18, 2025

View reviewed changes

sm-sayedi requested a review from gnprice July 18, 2025 18:16

gnprice reviewed Jul 18, 2025

View reviewed changes

sm-sayedi force-pushed the 197-P2 branch 2 times, most recently from a238b1c to 032110b Compare July 19, 2025 10:31

sm-sayedi commented Jul 19, 2025

View reviewed changes

sm-sayedi requested a review from gnprice July 19, 2025 10:42

gnprice reviewed Jul 22, 2025

View reviewed changes

sm-sayedi force-pushed the 197-P2 branch from 4eca289 to f903dca Compare July 22, 2025 14:26

sm-sayedi added 2 commits July 22, 2025 18:56

test store [nfc]: Make changeUserStatuses take a Map instead of a Record

ce10f39

msglist: Show user status emoji

c5cceed

gnprice and others added 2 commits July 22, 2025 18:56

recent-dms: Show user status emoji in recent DMs page

4bd0b8f

Status emojis are only shown for self-1:1 and 1:1 conversation items. They're ignored for group conversations as that's what the Web does.

sm-sayedi force-pushed the 197-P2 branch from f903dca to 1c1097d Compare July 22, 2025 14:29

sm-sayedi added 4 commits July 22, 2025 19:11

new-dm: Show user status emoji

13b9266

autocomplete [nfc]: Make MentionAutocompleteItem visibleForTesting

a34be77

autocomplete: Show user status emoji in user-mention autocomplete

e960fd8

profile: Show user status

3121e13

Fixes: zulip#197

sm-sayedi force-pushed the 197-P2 branch from 1c1097d to 3121e13 Compare July 22, 2025 14:45

sm-sayedi requested a review from gnprice July 22, 2025 14:47

		check((emojiFinder
		.evaluate().first.widget as UserStatusEmoji).neverAnimate).equals(!isAnimated);

	padding: const EdgeInsetsDirectional.only(start: 5.0))]),
	padding: const EdgeInsetsDirectional.only(start: 5.0)),
	]),

		color: DesignVariables.of(context).userStatusText)),

		if (displayEmail != null)

	checkStatusEmoji(tester, type: UnicodeEmojiWidget, isPresent: true);
	checkFindsStatusEmoji(tester, find.text('\u{1f6e0}'));

		title = TextSpan(children: [
		TextSpan(text: store.selfUser.fullName),

	title = TextSpan(children: [
	TextSpan(text: store.selfUser.fullName),
	title = TextSpan(text: store.selfUser.fullName, children: [

		TextSpan(children: [
		TextSpan(text: store.userDisplayName(userId)),

		check(statusEmojiFinder).findsOne();
		check(tester.firstWidget<UserStatusEmoji>(statusEmojiFinder)

		matching: find.text(expectedText),
		matching: find.textContaining(expectedText),

Show user status in UI #1702

Are you sure you want to change the base?

Show user status in UI #1702

Conversation

sm-sayedi commented Jul 10, 2025

Uh oh!

gnprice commented Jul 10, 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!

sm-sayedi commented Jul 17, 2025

Uh oh!

gnprice commented Jul 17, 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!

sm-sayedi commented Jul 18, 2025

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!

gnprice left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment