emoji: Fix bottom padding of emoji picker

[PIG208]

Previously, the body of the bottom sheet was wrapped in SafeArea. This pads the bottom unconditionally, shifting the bottom of the list view above the device bottom inset.

This is undesirable, because the area beneath the bottom inset is still visible, and the list view should extend to the bottom regardless of the bottom inset.

By just removing the SafeArea, the list view extends to the bottom. However, if the bottom inset is more than 8px, we can't scroll past the last item in the list view. Essentially, we want the behavior of SafeArea.minimum with a ListView — the bottom of the list should always be padded by at least 8px, so that we can scroll past the shadow; and if the bottom inset is more than 8px, use that as the padding instead — which is achieved through the use ListView.padding and MediaQuery.

[PIG208]

Comparisons (older revision)

The bottom bar represents the device padding.

before (SafeArea + 8px bottom padding)	after max(8px, bottom inset) bottom padding
partially scrolled to the bottom, with shadow visible
fully scrolled to the bottom
with keyboard open, unscrolled

Comparisons (w/ `CustomScrollView` and `SilverSafePadding`)

before (SafeArea + 8px bottom padding)	after (SilverSafePadding)
partially scrolled to the bottom, with shadow visible
fully scrolled to the bottom
with keyboard open, unscrolled

(This set of screenshots appear consistent with the older implementation; both should fix this issue)

Comparisons (w/ `CustomScrollView` and `SilverSafePadding` and no shadow)

before (SafeArea + 8px bottom padding)	after (SilverSafePadding)
partially scrolled to the bottom
fully scrolled to the bottom
with keyboard open, unscrolled

The following patch was used to make the builds in the screenshots:

diff --git a/lib/widgets/app.dart b/lib/widgets/app.dart
index 2ad35e3e5..28a96cf68 100644
--- a/lib/widgets/app.dart
+++ b/lib/widgets/app.dart
@@ -201,6 +201,7 @@ class _ZulipAppState extends State<ZulipApp> with WidgetsBindingObserver {
   @override
   Widget build(BuildContext context) {
     final themeData = zulipThemeData(context);
+    final mediaQuery = MediaQuery.of(context);
     return GlobalStoreWidget(
       child: MaterialApp(
         onGenerateTitle: (BuildContext context) {
@@ -218,7 +219,21 @@ class _ZulipAppState extends State<ZulipApp> with WidgetsBindingObserver {
               (_) => widget._declareReady());
           }
           GlobalLocalizations.zulipLocalizations = ZulipLocalizations.of(context);
-          return child!;
+          return Center(child: Stack(
+            children: [
+              MediaQuery(
+                data: mediaQuery.copyWith(
+                  viewPadding: mediaQuery.viewPadding.copyWith(bottom: 30),
+                  padding: mediaQuery.padding.copyWith(bottom: 30),
+                ),
+                child: child!),
+              Positioned(
+                left: 0,
+                right: 0,
+                bottom: 0,
+                child: Container(height: 30, decoration: BoxDecoration(color: Colors.black.withValues(alpha: 0.5)))),
+            ],
+          ));
         },
 
         // We use onGenerateInitialRoutes for the real work of specifying the

[chrisbobbe]

Thanks! Comments below.

I stopped reading the tests when I realized they might not work with an alternative implementation I thought of. (Actually would it be possible to write a set of tests that would work with either/any implementation? That's generally preferable.)

[chrisbobbe]

I don't understand this yet—what do you mean by "remove the bottom inset"?

Here's the doc:

/// The [useSafeArea] parameter specifies whether the sheet will avoid system
/// intrusions on the top, left, and right. If false, no [SafeArea] is added;
/// and [MediaQuery.removePadding] is applied to the top,
/// so that system intrusions at the top will not be avoided by a [SafeArea]
/// inside the bottom sheet either.
/// Defaults to false.

It doesn't say anything about controlling what's done about the bottom inset.

[chrisbobbe]

How about using CustomScrollView, with SliverPadding for the top padding and SliverSafeArea for the bottom padding? My feeling is that the code would be simpler; I'm curious if that turns out to be true. We use SliverSafeArea in a few places already.

[PIG208]

Indeed! This works for me:

      Expanded(child: InsetShadowBox(
        top: 8, bottom: 8,
        color: designVariables.bgContextMenu,
        child: CustomScrollView(
          slivers: [
            SliverPadding(
              padding: EdgeInsets.only(top: 8),
              sliver: SliverSafeArea(
                minimum: EdgeInsets.only(bottom: 8),
                sliver: SliverList.builder(
                  itemCount: _resultsToDisplay.length,
                  itemBuilder: (context, i) => EmojiPickerListEntry(
                    pageContext: widget.pageContext,
                    emoji: _resultsToDisplay[i].candidate,
                    message: widget.message)))),
          ]))),

[PIG208]

Updated the PR, with new screenshots here: #1315 (comment).

The new implementation does require reworking the tests. I have updated them with an approach that should work just fine with the emoji picker implementation on main.

[chrisbobbe]

Thanks! Reviewing now.

One nit: I think this is the wrong column label in the table of screenshots for the current revision:

after max(8px, bottom inset) bottom padding

because the max approach isn't used in this revision. I think just a copy-paste error from the other table of screenshots.

[chrisbobbe]

Thanks! One design-level comment I noticed: now that the content can scroll all the way to the bottom edge of the screen (which I also think is an improvement), how about removing the InsetShadowBox shadow effect at the bottom? We don't have that effect on similar scrollables, such as the "Combined feed" message list.

The shadow effect makes the viewport edge more graceful when there's not already a clear boundary that coincides with it, but the screen edge is such a boundary. Similarly the top edge of the keyboard when that's open. (Clear definition of the top edge of the keyboard is the platform's job, not ours.)

I'd be happy to discuss more in #mobile-design if needed.

[chrisbobbe]

Suggested change

	final options = tester.widgetList(find.byType(EmojiPickerListEntry));
	firstOption = options.first;
	lastOption = options.last;
	final listEntryFinder = find.byType(EmojiPickerListEntry);
	firstOption = tester.widget(listEntryFinder.first);
	lastOption = tester.widget(listEntryFinder.last);

with the goal of leaning on flutter_test just a little bit more, in case it gives richer / more helpful feedback when a test fails—I don't know if it actually would in this case though.

Actually, with these chained finders (foo.first and foo.last), would we still need to store firstOption and lastOption to pass to a find.byWidget, or could we just used the chained finders directly?

[chrisbobbe]

The name, return type, and implementation don't seem to fit with each other; I can say more if helpful.

[PIG208]

Yeah, I kind of struggled naming these helpers. I meant to express that this fetches y-coord of the top-most/bottom-most edge of the scrollable content (scroll items/scroll list?).

Are double getScrollElementTopEdgeDy and double getScrollElementBottomEdgeDy better?

[chrisbobbe]

It looks like this assumes there's a very long list of children, but I'm not seeing that clearly in the setup code. Reading setupEmojiPicker, called by prepare, I think I see two items being set up?

      store.setServerEmojiData(ServerEmojiData(codeToNames: {
        '1f4a4': ['zzz', 'sleepy'], // (just 'zzz' in real data)
      }));
      await store.handleEvent(RealmEmojiUpdateEvent(id: 1, realmEmoji: {
        '1': eg.realmEmojiItem(emojiCode: '1', emojiName: 'buzzing'),
      }));

[PIG208]

The rest of them come from EmojiStore.popularEmojiCandidates.

The test controls the screen height so that the scroll view can be filled. I think we can add some additional checks in prepare to verify that.

[chrisbobbe]

I don't know what "removes insets" means. Taken literally, it doesn't make sense; the insets are features of the device (which might include hardware) that our app isn't able to remove.

How about:

    // The bottom inset is left for [builder] to handle;
    // see [EmojiPicker] and its [CustomScrollView] for how we do that.

It's also possible that we don't need a comment at all, and the useSafeArea dartdoc is sufficient if readers are curious.

[PIG208]

Thanks for the review! Just pushed a new revision addressing the comments, and updated the screenshots.

[chrisbobbe]

Thanks! Small comments on the tests, which actually I'm curious for Greg's thoughts on (so, marking for his review): one is a naming question, the other is about adding a helper that might be helpful but maybe not necessary.

[chrisbobbe]

This is a way to let callers use less code, but it doesn't really remove the caller's burden to think about the physical/logical pixel distinction. That's because callers are still asked to make a FakeViewPadding, and the dartdoc of that says it's in physical pixels, while the rest of the test code is naturally in logical pixels. Callers are asked to assume the pixel ratio is 1, but they're not asked explicitly, in prepare's interface (it has no dartdoc), so they have to look at this line in the implementation, to be sure.

It's helpful that we're not asking callers to do math with devicePixelRatio, but I think there's a more satisfying way to do that, and with something reusable. (Helpful because this is likely to come up again.) What if we did this:

• New file, like test/test_window.dart
• New private subclass of FakeViewPadding:
  • It implements a method FakeViewPadding resolve(double devicePixelRatio) that returns a plain FakeViewPadding, scaled from this by devicePixelRatio
  • Its left, top, right, and bottom getters throw errors saying that resolve must be called. (Or maybe call the superclass's getter just if the value is zero.) See for example the operator getter on ApiNarrowDm.
• An extension on FakeViewPadding, adding a static method with return type FakeViewPadding, named something like fromLogicalPx, that creates and returns an instance of the private subclass

Then for these tests, callers would say:

FakeViewPadding.fromLogicalPx(bottom: 10)

and prepare would say

        tester.view.viewPadding = viewPadding.resolve(devicePixelRatio);

[chrisbobbe]

Are the finders restricted to list entries that are at least partially visible in the viewport, and do the tests depend on that? If so, maybe that should be reflected in these names. I agree naming these is hard 😅 #1315 (comment) —maybe Greg would have some thoughts, having recently worked with the sticky-header code.