Offer "Invisible mode" toggle switch! #1631

chrisbobbe · 2025-06-26T06:06:23Z

~~Still TODO: tests.~~

Some known differences from the Figma, which won't be hard to fix but require upstream changes, so not totally trivial:

When the switch is on:
- The switch should be 28px by 48px, not 36px by 56px.
- The "thumb" (white circle with checkmark) should have radius 10px, not 12px.
When the switch is off:
- The switch should be 26px by 46px, not 34px by 54px.
- The "thumb" should have radius 7px, not 8px.

(edit: screenshots of what it would look like with these differences resolved: #1631 (comment) , and I filed #1636 for these fixes)

Fixes: #1578

chrisbobbe · 2025-06-26T06:13:50Z

Self-profile

Light	Dark

Non-self profile (no change):

Light	Dark

chrisbobbe · 2025-06-26T19:17:15Z

Here's how it could look after some upstream work (flutter/flutter#131478). This removes the differences from the Figma that I mentioned in the PR description:

Screenshots

Before	After

chrisbobbe · 2025-06-26T19:31:38Z

And I did go ahead and download GIPHY CAPTURE to record the animation and drag behavior 🙂:

(This is the PR as-is, not with the upstream work from my previous comment)

The switch responds to taps	The button responds to taps	The "thumb" responds to dragging

chrisbobbe · 2025-06-26T19:39:15Z

Error feedback when failing to turn mode on / off, and tapping the "Details" button in the snackbar.

The "Details" dialog isn't user-friendly. We could omit the "Details" button, but it might be helpful for debugging unexplained failures.

On	Off

alya · 2025-06-26T19:54:49Z

Yeah, I guess depends on how much we expect users to actually send us those details. If not, probably not super helpful to show them, unless we can translate them to something more readable (e.g., just say "Network error" or "Couldn't connect to server." or something).

timabbott · 2025-06-26T20:07:17Z

I think Sentry is for debugging, and we want some generic network error as the thing to present in the UI.

chrisbobbe · 2025-06-26T20:11:59Z

Makes sense; here's with the "Details" button removed:

Light/On	Dark/Off

chrisbobbe · 2025-06-26T20:14:14Z

(And I'll add a TODO(#741) for interpreting the error)

rajveermalviya

Thanks for working on this @chrisbobbe! Works great in local testing.

Couple small comments, and I see that the some tests are TODO (e.g. PerAccountSettingBuilder), otherwise LGTM.

rajveermalviya · 2025-06-30T13:56:59Z

lib/widgets/per_account_settings.dart

+ /// so until the spam-taps are finished, the switch responds only to the taps,
+ /// not to the event stream.
+ /// Then when the taps stop, it settles to the value from the latest event.)
+ static final Duration localEchoMininum = Duration(seconds: 1);


nit:

Suggested change

static final Duration localEchoMininum = Duration(seconds: 1);

static final Duration localEchoMinimum = Duration(seconds: 1);

rajveermalviya · 2025-06-30T14:18:48Z

lib/widgets/per_account_settings.dart

+ });
+
+ }


nit:

Suggested change

});

}

});

}

chrisbobbe · 2025-07-07T05:58:03Z

Thanks for the review! Revision pushed, with some tests added.

gnprice

Thanks! Generally this looks great; comments below.

I haven't yet read all the logic in PerAccountSettingBuilder (pending a couple of questions / requests for dartdoc below), or the tests in the last commit. I've read everything else, so including everything before the last commit:
57da943 api: Require InitialSnapshot.userSettings, present since Zulip Server 5
ebdb035 api: Add InitialSnapshot.userSettings.presenceEnabled
f373c94 api: Add updateSettings
4f114af button [nfc]: Extract MenuButton{,sShape} out to here, from action sheet
847b326 button: Fix an inconsistency with Figma in MenuButton
3e496ec button: Give MenuButton a beforeIcon param, to use for a switch
f5598f5 button [nfc]: Factor MenuButton's vertical padding as around just the text
428e97e button: Implement "toggle" component from Figma, for "Invisible mode"
ed544a7 profile test [nfc]: Rename group about custom fields; pull out some tests

and part of that last commit:
a71d75d profile: Add toggle switch for "Invisible mode", with local echo

gnprice · 2025-07-07T19:28:32Z

lib/api/route/settings.dart

+part 'settings.g.dart';
+
+/// https://zulip.com/api/update-settings
+Future<UpdateSettingsResult> updateSettings(ApiConnection connection, {


nit:

api: Add updateSettings

add the word "route" at the end — it wasn't clear to me before reading the code what sort of a thing "updateSettings" was

gnprice · 2025-07-07T19:29:06Z

lib/api/model/initial_snapshot.dart

 // (1) add it to the [UserSettingName] enum
 // (2) then re-run the command to refresh the .g.dart files
 // (3) handle the event that signals an update to the setting
+ // (4) add the setting to the updateSettings binding


nit: similarly,

Suggested change

// (4) add the setting to the updateSettings binding

// (4) add the setting to the [updateSettings] route binding

gnprice · 2025-07-07T19:31:08Z

lib/api/route/settings.dart

+class UpdateSettingsResult {
+ UpdateSettingsResult();
+
+ factory UpdateSettingsResult.fromJson(Map<String, dynamic> json) =>


Since there's no content in this result, we can skip it — just have the endpoint function return Future<void>. Grep for "Future" in this directory to see other examples.

gnprice · 2025-07-07T19:36:24Z

test/api/route/settings_test.dart

+ final newSettings = <UserSettingName, Object?>{};
+ final expectedBodyFields = <String, String>{};
+
+ for (final name in UserSettingName.values) {


nit: join declarations with their initializers

Suggested change

final newSettings = <UserSettingName, Object?>{};

final expectedBodyFields = <String, String>{};

for (final name in UserSettingName.values) {

final newSettings = <UserSettingName, Object?>{};

final expectedBodyFields = <String, String>{};

for (final name in UserSettingName.values) {

gnprice · 2025-07-07T19:37:15Z

test/api/route/settings_test.dart

+ for (final name in UserSettingName.values) {
+ switch (name) {
+ case UserSettingName.twentyFourHourTime:
+ newSettings[name] = true;
+ expectedBodyFields['twenty_four_hour_time'] = 'true';
+ case UserSettingName.displayEmojiReactionUsers:


Interesting, so this ensures that future additions to the enum get tested on this endpoint.

gnprice · 2025-07-07T20:22:48Z

lib/widgets/per_account_settings.dart

+ }
+}
+
+class _LocalEchoNotifier<T> extends ValueNotifier<_LocalEchoValue<T>?> {


I think this would benefit from a short dartdoc: particularly on what it means to have a value here, or for [value] to be null.

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

lib/widgets/per_account_settings.dart

+ });
+ }
+
+ Future<void> stop() async {


Also good to document would be what this Future represents — what does it mean to await it?

gnprice · 2025-07-07T20:29:59Z

lib/widgets/profile.dart

+ if (!store.realmPresenceDisabled && userId == store.selfUserId) ...[
+ const SizedBox(height: 16),
+ MenuButtonsShape(buttons: [


Let's pull this whole MenuButtonsShape subtree out to its own widget — e.g. call it _InvisibleModeToggle — so that this just has the condition, the spacers, and a reference to that widget. I think that'll help keep this more organized to read.

(The same might also be good for some of these other items; but this is more complex than any of the existing items here. And conversely it doesn't share interactions like oh they're all centered, they're all using _TextStyles.primaryFieldText, which are advantages to having the others inline next to each other.)

gnprice · 2025-07-07T20:32:35Z

lib/widgets/profile.dart

+ findValueInStore: (store) => !store.userSettings.presenceEnabled,
+ sendValueToServer: (value) => updateSettings(store.connection,
+ newSettings: {UserSettingName.presenceEnabled: !value}),


Hmm, interesting that findValueInStore gets passed the store to use, but then sendValueToServer ends up using the store it got from the parent widget.

(This is fine to ship, doesn't need to be refactored, but feels like it suggests the API could ideally be adjusted)

gnprice · 2025-07-07T20:34:11Z

lib/widgets/button.dart

+ children: [
+ if (beforeIcon != null) beforeIcon!,
+ if (icon != null) Icon(icon, color: designVariables.contextMenuItemText),


Interesting that this provides for both an icon and some other widget before it. Are there examples of that in the Figma designs?

Yeah at the Figma link in the dartdoc 🙂:

https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=6070-60681&m=dev

I see, indeed 😄

The name "before icon" feels like it doesn't quite get to the point — I feel like I have to think a bit to work through what it's supposed to end up meaning. And in the current example, as the dartdoc says:

/// An element to go before [icon], or in its place if it's null. /// /// E.g. a [Toggle]. final Widget? beforeIcon;

this "before icon" widget appears even though there is no icon.

How about a name like "control"? It's the visible control in the button, when the button has such a thing.

Or perhaps with less generalization: "toggle"? That's the name it has in that Figma subtree: the children are "label", "toggle", "icon". If we later have a menu button somewhere that has some other kind of widget in here other than a toggle, I'm not sure we'll necessarily want to treat it the same way.

chrisbobbe · 2025-07-07T23:16:18Z

Thanks for the review! Revision pushed.

chrisbobbe · 2025-07-07T23:24:23Z

And pushed again, with the "before icon" / "toggle" change suggestion #1631 (comment)

gnprice

Thanks for the revisions! Just read the changes and re-scanned my comments above; all looks good except a few small comments below.

Next I'll read the remaining parts of the last/main commit, as mentioned at #1631 (review).

gnprice · 2025-07-07T23:19:41Z

test/widgets/profile_test.dart

+ check(because: 'find error icon', find.byIcon(Icons.error).evaluate()).isNotEmpty();
+ });
+
+ testWidgets('page builds; dm links to correct narrow', (tester) async {


nit:

Most of the tests in this ProfilePage group are about custom profile fields. Pull out the two that aren't, and rename the group.

s/two/handful/ or some other update 🙂 (after #1631 (comment))

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

lib/widgets/per_account_settings.dart

+/// But the local echo minimizes flickering (see [localEchoMinimum])
+/// while ensuring that the real in-store value is shown soon after the
+/// user finishes interacting, whether the request(s) succeeded or failed.
+typedef PerAccountSettingBuilderFn<T> =


nit: rename this to match the class; rename the file, too

gnprice · 2025-07-07T23:22:24Z

lib/widgets/per_account_settings.dart

+///
+/// If extending a local-echo period, replaces the old local-echo value.
+///
+/// This may be called any time. API requests are not debounced,


"this" should be [handleRequestNewValue], right? Not the function whose type this is documenting.

gnprice · 2025-07-07T23:23:38Z

lib/widgets/per_account_settings.dart

+ /// The session will be stopped either immediately or
+ /// [RemoteSettingBuilder.localEchoMinimum] after the last [startOrExtend] call,
+ /// whichever is later.
+ ///
+ /// The returned [Future] resolves when the session is stopped.
+ Future<void> stop() async {


Very helpful, thanks.

gnprice

OK, and finished reading the rest. Generally this all looks good — comments below, most notably some checks missing in the tests.

gnprice · 2025-07-07T23:33:52Z

lib/widgets/per_account_settings.dart

+ final value = switch (_notifier.value) {
+ OptionSome(:final value) => value,
+ OptionNone() => widget.findValueInStore(store),
+ };


I guess this would be a use case for adding an orElse:

Suggested change

final value = switch (_notifier.value) {

OptionSome(:final value) => value,

OptionNone() => widget.findValueInStore(store),

};

final value = _notifier.value.orElse(() => widget.findValueInStore(store));

(taking API inspiration from Rust's Option, per the Option dartdoc)

This version is fine, though.

gnprice · 2025-07-07T23:34:33Z

lib/widgets/per_account_settings.dart

+ // (Create the PerAccountStoreWidget dependency unconditionally.)
+ final store = PerAccountStoreWidget.of(context);


Is there a reason we actively want to do this? That's what I take the comment to mean, but then I'm curious what the reason is 🙂

(I think it's harmless to do so — in fact we'll always have the dependency anyway before even reaching the build method, because we use it from didChangeDependencies)

I think my thinking was:

didChangeDependencies needs to be called when local-echo isn't active, which means the dependency needs to exist when local-echo isn't active

The (only) way to create a dependency is by calling PerAccountStoreWidget.of in the build method; it doesn't count if we call it in didChangeDependencies

The dependency might disappear if a build call doesn't call PerAccountStoreWidget.of (I remember being pretty sure about this but can't right away find where I read about it)

I think I was indeed wrong on the second point though 🙂—

/// This method should not be called from widget constructors or from /// [State.initState] methods, because those methods would not get called /// again if the inherited value were to change. To ensure that the widget /// correctly updates itself when the inherited value changes, only call this /// (directly or indirectly) from build methods, layout and paint callbacks, /// or from [State.didChangeDependencies] (which is called immediately after /// [State.initState]).

so yeah, the comment isn't guarding against a potential bug, and I'll remove it.

The dependency might disappear if a build call doesn't call PerAccountStoreWidget.of (I remember being pretty sure about this but can't right away find where I read about it)

There've been occasional requests upstream for this behavior. But the current behavior is that once an element has a dependency, it keeps it throughout its lifetime; there's no attempt to clear out dependencies.

See background here:
flutter/flutter#12992 (comment)

Good to know, thanks!

gnprice · 2025-07-07T23:38:07Z

lib/widgets/per_account_settings.dart

+ if (_disposed) return;
+ // Don't call _notifier.stop(). We do that when the event arrives,
+ // causing the in-store value to change (see didChangeDependencies).
+ } catch (e) {


This is potentially a real error, so let's leave a TODO(log) comment:

Suggested change

} catch (e) {

} catch (e) { // TODO(log)

gnprice · 2025-07-07T23:39:31Z

lib/widgets/profile.dart

+}
+
+
 class _ProfileErrorPage extends StatelessWidget {


nit: double blank line

gnprice · 2025-07-07T23:41:38Z

lib/widgets/per_account_settings.dart

+ factory _LocalEchoNotifier() {
+ return _LocalEchoNotifier._(OptionNone());
+ }
+
+ _LocalEchoNotifier._(super.value);


nit: can simplify:

Suggested change

factory _LocalEchoNotifier() {

return _LocalEchoNotifier._(OptionNone());

}

_LocalEchoNotifier._(super.value);

_LocalEchoNotifier() : super(OptionNone());

gnprice · 2025-07-07T23:49:55Z

lib/widgets/per_account_settings.dart

+ void dispose() {
+ _lowerBoundTimer?.cancel();
+ _upperBoundTimer?.cancel();
+ _disposed = true;
+ super.dispose();


Also _lowerBoundCompleter?.complete()?

Otherwise, I think if there's an outstanding stop call awaiting the completer's future, then that will hang around forever because the future never completes. Which might then keep a _handleRequestNewValue call hanging around, and therefore the state object and widget object, and so on.

gnprice · 2025-07-07T23:58:16Z

test/widgets/profile_test.dart

+ final toggle = tester.widget<Toggle>(findToggle);
+ check(toggle.value).equals(expected);


nit: this is equivalent, right?

Suggested change

final toggle = tester.widget<Toggle>(findToggle);

check(toggle.value).equals(expected);

check(getValue(tester)).equals(expected);

gnprice · 2025-07-08T00:02:07Z

test/widgets/profile_test.dart

+ // Events will be coming in, but those don't control the switch;
+ // only the user interaction does, until there have been no interactions
+ // for [PerAccountSettingBuilder.localEchoMinimum].
+ await doSpamTap();
+ await tester.pump(Duration(milliseconds: 90));
+ await doSpamTap();


It doesn't seem like these actually check that events don't control the switch.

In fact I tried deleting the key part of stop:

Future<void> stop() async { - if (_lowerBoundCompleter != null) { - await _lowerBoundCompleter!.future; - if (_disposed) return; - } value = OptionNone(); }

and it seems tests still pass.

Eep, indeed! Will fix.

gnprice · 2025-07-08T00:03:32Z

test/widgets/profile_test.dart

+ checkAppearsActive(tester, true);
+ checkRequest(true);
+
+ // After [PerAccountSettingBuilder.localEchoMinimum], changes back
+ await tester.pump(RemoteSettingBuilder.localEchoMinimum);


Similarly, this should gain a check that the appearance doesn't change before that minimum (when the request failure comes back).

chrisbobbe · 2025-07-08T01:20:52Z

Thanks! Revision pushed.

gnprice

Thanks for the revision! Just small comments now.

gnprice · 2025-07-08T01:29:13Z

lib/basic.dart

+ /// The value contained in this option, if any;
+ /// else the value returned by [fn].
+ T orElse(T Function() fn);


nit: specify the other key piece of this method's semantics:

Suggested change

/// The value contained in this option, if any;

/// else the value returned by [fn].

T orElse(T Function() fn);

/// The value contained in this option, if any;

/// else the value returned by [fn].

///

/// [fn] is called only if its return value is needed.

T orElse(T Function() fn);

Oh and I guess test that too, e.g. by having the callback throw.

gnprice · 2025-07-08T01:35:38Z

test/widgets/profile_test.dart

+ // The appearance doesn't change as soon as the request errors,
+ // if it errored quickly…
+ await tester.pump(requestDuration);
+ checkAppearsActive(tester, true);


We've seen elsewhere (those route transitions) that sometimes one needs to call tester.pump for a duration that's epsilon longer than nominally should be necessary in order to get something to happen.

So when a test is, like here, checking that something doesn't happen, it's not entirely convincing as a reader unless it waits for a bit longer than the nominal time, for good measure.

Could say requestDuration + Duration(milliseconds: 1). Or could say like Duration(milliseconds: 101), or Duration(milliseconds: 200), and let the reader compare to the 100ms constant above.

gnprice · 2025-07-08T01:36:58Z

test/widgets/profile_test.dart

+ await doSpamTap(expectedCurrentValue: false);
+
+ await tester.pump(RemoteSettingBuilder.localEchoMinimum - Duration(milliseconds: 1));
+ check(getValue(tester)).equals(true);


nit: I think a bit more explicitness would help understanding here:

Suggested change

await doSpamTap(expectedCurrentValue: false);

await tester.pump(RemoteSettingBuilder.localEchoMinimum - Duration(milliseconds: 1));

check(getValue(tester)).equals(true);

await doSpamTap(expectedCurrentValue: false);

check(getValue(tester)).equals(true);

await tester.pump(RemoteSettingBuilder.localEchoMinimum - Duration(milliseconds: 1));

check(getValue(tester)).equals(true);

(That is the right expectation, right?)

alya · 2025-07-08T20:41:47Z

I left a design comment on CZO: #mobile-design > presence: invisible mode @ 💬

gnprice · 2025-07-09T02:34:26Z

I'm planning to include this PR in a v30.0.261 release tomorrow. It'd be great to have it merged first, and to have that design tweak made.

chrisbobbe · 2025-07-09T05:05:14Z

Thanks for the reviews and design guidance! Revision pushed, with three new commits:

60a3e2b button: Fix MenuButton's icon color
84181e8 button [nfc]: Add "list button" variant, factored into MenuButton widget
36d9735 profile: Change "Invisible mode" toggle to more neutral "list button" style

The first of those fixes a bug in main where we had the wrong icon color in action sheets, only in light mode:

Before	After

New screenshots:

Switch on	Switch off

chrisbobbe · 2025-07-09T18:15:07Z

Thanks both! Revision pushed.

gnprice

Thanks! Looks good; one nit and a small question.

gnprice · 2025-07-09T19:43:16Z

lib/widgets/button.dart

+ if (ancestor != null) return true;
+ throw FlutterError.fromParts([
+ ErrorSummary('No MenuButtonsShape ancestor found.'),
+ ErrorDescription('MenuButton widgets require a MenuButtonsShape ancestor.'),


nit: one stray reference here to the MenuButton name

gnprice · 2025-07-09T19:47:31Z

lib/widgets/theme.dart

+ contextMenuItemIcon: const Color(0xff4f42c9),
 contextMenuItemLabel: const Color(0xff242631),
 contextMenuItemMeta: const Color(0xff626573),
 contextMenuItemText: const Color(0xff381da7),


button: Fix MenuButton's icon color Oops, this wasn't following the Figma. Fixed.

Hmm good catch.

I guess this affects the icons in the action sheets? Is that the existing place this affects?

Looks like the difference is pretty subtle, thankfully. Here's a quick preview, from my IDE showing color swatches in the left gutter next to the source code:

Bringing those right next to each other (new above, old below):

Yep yep, and I posted a screenshot of the change in the action sheet: #1631 (comment)

Ah indeed, thanks :-)

Related: zulip#268

Most of the tests in this ProfilePage group are about custom profile fields. Pull out some that aren't, and rename the group.

The PerAccountSettingBuilder widget should be helpful for plenty of other things too, like channel settings. I think we'll get an updated design for the profile page soon, but pending that, this is our current thinking for how "Invisible mode" should look: https://chat.zulip.org/#narrow/channel/530-mobile-design/topic/presence.3A.20invisible.20mode/near/2204336 Fixes: zulip#1578

Oops, this wasn't following the Figma. Fixed.

And rename MenuButton to ZulipMenuItemButton, since it's no longer only about the Figma's "menu button" component.

… style

chrisbobbe · 2025-07-09T20:06:35Z

Thanks! Revision pushed.

gnprice · 2025-07-09T20:54:50Z

Thanks! Looks good; merging.

Added in zulip/zulip-flutter#1631.

Added in zulip/zulip-flutter#1631. (cherry picked from commit cb35d41)

chrisbobbe requested a review from rajveermalviya June 26, 2025 06:06

chrisbobbe added maintainer review PR ready for review by Zulip maintainers launch feedback Things users specifically asked for upon launch labels Jun 26, 2025

chrisbobbe force-pushed the pr-invisible-mode branch from 7fd821c to 4881bd5 Compare June 26, 2025 19:23

chrisbobbe force-pushed the pr-invisible-mode branch from 4881bd5 to 159c6d7 Compare June 26, 2025 20:14

chrisbobbe mentioned this pull request Jun 26, 2025

Refine Toggle dimensions to follow Figma spec #1636

Open

chrisbobbe force-pushed the pr-invisible-mode branch from 159c6d7 to b67ac62 Compare June 26, 2025 20:49

rajveermalviya approved these changes Jun 30, 2025

View reviewed changes

chrisbobbe force-pushed the pr-invisible-mode branch from b67ac62 to a71d75d Compare July 7, 2025 05:57

gnprice reviewed Jul 7, 2025

View reviewed changes

chrisbobbe force-pushed the pr-invisible-mode branch from a71d75d to f7ebd5a Compare July 7, 2025 23:16

chrisbobbe force-pushed the pr-invisible-mode branch from f7ebd5a to 62029e3 Compare July 7, 2025 23:24

gnprice reviewed Jul 7, 2025

View reviewed changes

gnprice reviewed Jul 8, 2025

View reviewed changes

chrisbobbe force-pushed the pr-invisible-mode branch from 62029e3 to d34e419 Compare July 8, 2025 01:20

gnprice reviewed Jul 8, 2025

View reviewed changes

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

chrisbobbe force-pushed the pr-invisible-mode branch from d34e419 to ada007e Compare July 9, 2025 04:56

chrisbobbe force-pushed the pr-invisible-mode branch 2 times, most recently from 36d9735 to 5cece3a Compare July 9, 2025 18:15

gnprice reviewed Jul 9, 2025

View reviewed changes

chrisbobbe and others added 13 commits July 9, 2025 13:04

api: Require InitialSnapshot.userSettings, present since Zulip Server 5

e6f4576

Related: zulip#268

api: Add InitialSnapshot.userSettings.presenceEnabled

af95d11

api: Add updateSettings route

8108762

button [nfc]: Extract MenuButton{,sShape} out to here, from action sheet

b8ccd55

button: Fix an inconsistency with Figma in MenuButton

2e6c293

button: Implement "toggle" component from Figma, for "Invisible mode"

10c647f

button: Give MenuButton an optional toggle param

cc8c022

profile test [nfc]: Split redundant group; make group for custom fields

f81a698

Most of the tests in this ProfilePage group are about custom profile fields. Pull out some that aren't, and rename the group.

basic: Add a generic Option class

b491bd7

button: Fix MenuButton's icon color

d5da314

Oops, this wasn't following the Figma. Fixed.

button [nfc]: Add "list button" variant, factored into MenuButton widget

28455d8

And rename MenuButton to ZulipMenuItemButton, since it's no longer only about the Figma's "menu button" component.

profile: Change "Invisible mode" toggle to more neutral "list button"…

9b5a637

… style

chrisbobbe force-pushed the pr-invisible-mode branch from 5cece3a to 9b5a637 Compare July 9, 2025 20:06

gnprice merged commit 9b5a637 into zulip:main Jul 9, 2025
1 check passed

gnprice mentioned this pull request Jul 9, 2025

Track user status #1629

Merged

laurynmm added a commit to laurynmm/zulip that referenced this pull request Jul 11, 2025

help: Add mobile instructions for toggling invisible mode.

2fddf1b

Added in zulip/zulip-flutter#1631.

laurynmm mentioned this pull request Jul 11, 2025

help: Add mobile instructions for toggling invisible mode. zulip/zulip#35219

Merged

12 tasks

timabbott pushed a commit to zulip/zulip that referenced this pull request Jul 11, 2025

help: Add mobile instructions for toggling invisible mode.

cb35d41

Added in zulip/zulip-flutter#1631.

timabbott pushed a commit to zulip/zulip that referenced this pull request Jul 16, 2025

help: Add mobile instructions for toggling invisible mode.

33a46db

Added in zulip/zulip-flutter#1631. (cherry picked from commit cb35d41)

loveucifer mentioned this pull request Jul 19, 2025

Fix/toggle dimensions 1636 #1723

Closed

	static final Duration localEchoMininum = Duration(seconds: 1);
	static final Duration localEchoMinimum = Duration(seconds: 1);

- });
- }
+ });
+ }

	// (4) add the setting to the updateSettings binding
	// (4) add the setting to the [updateSettings] route binding

		// (Create the PerAccountStoreWidget dependency unconditionally.)
		final store = PerAccountStoreWidget.of(context);

		final toggle = tester.widget<Toggle>(findToggle);
		check(toggle.value).equals(expected);

	final toggle = tester.widget<Toggle>(findToggle);
	check(toggle.value).equals(expected);
	check(getValue(tester)).equals(expected);

Offer "Invisible mode" toggle switch! #1631

Offer "Invisible mode" toggle switch! #1631

Uh oh!

Conversation

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

Uh oh!

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

Uh oh!

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

Uh oh!

chrisbobbe commented Jun 26, 2025

chrisbobbe commented Jun 26, 2025

alya commented Jun 26, 2025

timabbott commented Jun 26, 2025

chrisbobbe commented Jun 26, 2025

chrisbobbe commented Jun 26, 2025

rajveermalviya left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chrisbobbe commented Jul 7, 2025

gnprice left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chrisbobbe commented Jul 7, 2025

chrisbobbe commented Jul 7, 2025

gnprice left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gnprice left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chrisbobbe commented Jul 8, 2025

gnprice left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alya commented Jul 8, 2025

gnprice commented Jul 9, 2025

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

Uh oh!

chrisbobbe commented Jul 9, 2025

gnprice left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chrisbobbe commented Jul 9, 2025

Uh oh!

chrisbobbe commented Jun 26, 2025 •

edited

Loading

chrisbobbe commented Jun 26, 2025 •

edited

Loading

chrisbobbe commented Jun 26, 2025 •

edited

Loading

chrisbobbe commented Jul 9, 2025 •

edited

Loading