Keyboard can pop up on returning from lightbox or internal link

[gnprice]

Repro:

• On Android, visit a message list that has a compose box.
• Touch the content input to focus it. The keyboard appears.
• Dismiss the keyboard using either (a) the "back" gesture or button or (b) the keyboard's own button for being dismissed. The keyboard will vanish, making room again for the full height of the message list.
• Now scroll around the message list reading messages, and forget that you'd previously interacted with the compose box.
  • (There is a blinking cursor as a subtle reminder; that's its own issue, Text cursor keeps blinking after hiding keyboard, on Android #1097.)
• Then open some other page within the app, by doing any of the following:
  • Tap on some image or video, opening the lightbox.
  • Or tap an internal link in a message, opening a new message-list page.
  • Or tap a message sender's name or avatar, opening their profile page.
  • Or etc.
  • (On the other hand: if you tap an external link, opening a web browser within the app, then that will not reproduce this issue.)
• Navigate back out of the other page, using either (a) the "back" gesture or button or (b) the "back" or "close" button in the app bar.
• Expected: The message list reappears, looking the same as it did when you entered the lightbox.
• Actual: The message list reappears, but the keyboard pops up, occupying a swath of the screen.

This is a variant of #1097, and I assume it has the same root cause: after dismissing the keyboard in step 3 above, the text field is still focused. When it occurs, this symptom is much more obtrusive and annoying.

I learned about this symptom the other day from a longtime Zulip user who was trying out the Flutter beta app; he ran into this within the first few minutes.

[gnprice]

I think there are basically two strategies for solving this:

• Figure out why navigating back opens the keyboard, and make it not do so.

  The keyboard's appearing has to fundamentally be under our control, because it can be triggered by the "back"/"close" button in an app bar. That's a gesture that's meaningful only to the app and the Flutter framework — the OS doesn't know anything about it — so the framework must be doing something that signals the keyboard to appear, presumably from the navigator code.

  OTOH in situations where a text field is focused and the keyboard is open, it might be annoying if navigating to some other page and back caused the keyboard to go away.

• When the user dismisses the keyboard, unfocus the text field too.

  I'm not sure if there's a clean way to make this happen — to notice specifically when the keyboard gets dismissed. A crude hack that'd mostly work would be to watch for changes to our viewport that look like the keyboard getting dismissed.

• (A third strategy I don't intend to use: we could pass ScrollViewKeyboardDismissBehavior.onDrag to the message list's scroll view, so that trying to scroll causes the keyboard to vanish and the text input to lose focus. See reasoning in chat for why this would be annoying behavior.)

The second strategy is what Discord does. (I don't know if they've found a clean way to do it or are using that crude hack.)

• Or at least they cause the blinking cursor to disappear from the text field when the keyboard is dismissed. I take the lack of cursor as indicating a lack of focus.

The first strategy is what Facebook Messenger does and what Slack does.

• In Slack's case, opening the lightbox and coming back also has the side effect that the text field loses focus — or anyway the blinking cursor in it disappears.
• In FB Messenger, that side effect doesn't occur: the blinking cursor remains.

[PIG208]

Figure out why navigating back opens the keyboard, and make it not do so.

This looks like flutter/flutter#94249.

We linked to this issue back in #552 (comment), but I think the bug applies here better.

[PIG208]

so the framework must be doing something that signals the keyboard to appear, presumably from the navigator code

My theory is that a FocusScope gets created when a route is pushed, causing the TextField to lose focus to the new level in the focus hierarchy:

/// A [FocusScope] is similar to a [Focus], but also serves as a scope for its
/// descendants, restricting focus traversal to the scoped controls.
///
/// For example a new [FocusScope] is created automatically when a route is
/// pushed, keeping the focus traversal from moving to a control in a previous
/// route.
/// [...]
class FocusScope extends Focus {

then, the _handleFocusChanged method of EditableText responds to this by calling _openOrCloseInputConnectionIfNeeded, among other things, closing the input connection that causes the keyboard to be hidden.

  void _handleFocusChanged() {
    _openOrCloseInputConnectionIfNeeded();
    _startOrStopCursorTimerIfNeeded();
    _updateOrDisposeSelectionOverlayIfNeeded();
    if (_hasFocus) {
      // Listen for changing viewInsets, which indicates keyboard showing up.
      WidgetsBinding.instance.addObserver(this);
      _lastBottomViewInset = View.of(context).viewInsets.bottom;
      if (!widget.readOnly) {
        _scheduleShowCaretOnScreen(withAnimation: true);
      }
      final TextSelection? updatedSelection = _adjustedSelectionWhenFocused();
      if (updatedSelection != null) {
        _handleSelectionChanged(updatedSelection, null);
      }
    } else {
      WidgetsBinding.instance.removeObserver(this);
      setState(() {
        _currentPromptRectRange = null;
      });
    }
    updateKeepAlive();
  }

I believe that the input connection is relevant to the keyboard being shown by looking at EditableTextState.requestKeyboard:

  /// Express interest in interacting with the keyboard.
  ///
  /// If this control is already attached to the keyboard, this function will
  /// request that the keyboard become visible. Otherwise, this function will
  /// ask the focus system that it become focused. If successful in acquiring
  /// focus, the control will then attach to the keyboard and request that the
  /// keyboard become visible.
  void requestKeyboard() {
    if (_hasFocus) {
      _openInputConnection();
    } else {
      _flagInternalFocus();
      widget.focusNode
          .requestFocus(); // This eventually calls _openInputConnection also, see _handleFocusChanged.
    }
  }

Because the focus on the TextField never goes away on the FocusScope when the user hides the keyboard, navigating back causes the keyboard to be shown again.

We could borrow EditableText's implementation for detecting keyboard changes, and unfocus it if the keyboard was actively hidden. This relies on checking the delta of bottom viewInsets with didChangeMetrics.

  @override
  void didChangeMetrics() {
    if (!mounted) {
      return;
    }
    final ui.FlutterView view = View.of(context);
    if (_lastBottomViewInset != view.viewInsets.bottom) {
      SchedulerBinding.instance.addPostFrameCallback((Duration _) {
        _selectionOverlay?.updateForScroll();
      }, debugLabel: 'EditableText.updateForScroll');
      if (_lastBottomViewInset < view.viewInsets.bottom) {
        // Because the metrics change signal from engine will come here every frame
        // (on both iOS and Android). So we don't need to show caret with animation.
        _scheduleShowCaretOnScreen(withAnimation: false);
      }
    }
    _lastBottomViewInset = view.viewInsets.bottom;
  }

[PIG208]

This all seem to be a side-effect of how focus is retained after navigating away, and how EditableText handles focus changes. For Android at least, if the keyboard is dismissed, it's a feature question as to whether to unfocus the EditableText or not.

It's not certain that the behavior of unfocusing is correct either, as sometimes the keyboard can be hidden while the input connection is still needed (flutter/flutter#142930 (comment), flutter/flutter#148475 (comment)).

[sm-sayedi]

then, the _handleFocusChanged method of EditableText responds to this by calling _openOrCloseInputConnectionIfNeeded, among other things, closing the input connection that causes the keyboard to be hidden.

That's exactly what happens. I forgot to put a link to the related CZO discussion in here. There's a complete method call stack on how it happens and a solution for the bug, which involves creating an upstream PR. There's also another possibility for the problem to be solved which I will test in these days.