1. 07 Mar, 2024 1 commit
    • Bruno Leroux's avatar
      [flutter_test] Change KeyEventSimulator default transit mode (#143847) · 8ade81fb
      Bruno Leroux authored
      ## Description
      
      This PRs changes the default value transit mode for key event simulation.
      
      The default transit mode for key event simulation is currently `KeyDataTransitMode.rawKeyData` while on the framework side `KeyDataTransitMode.keyDataThenRawKeyData` is the preferred transit mode.
      
      `KeyDataTransitMode.keyDataThenRawKeyData` is more accurate and can help detect issues.
      
      For instance the following test will fail with `KeyDataTransitMode.rawKeyData` because raw keyboard logic for modifier keys is less accurate:
      
      ```dart
        testWidgets('Press control left once', (WidgetTester tester) async {
          debugKeyEventSimulatorTransitModeOverride = KeyDataTransitMode.keyDataThenRawKeyData;
      
          final List<KeyEvent> events = <KeyEvent>[];
          final FocusNode focusNode = FocusNode();
          addTearDown(focusNode.dispose);
      
          await tester.pumpWidget(
            Focus(
              focusNode: focusNode,
              autofocus: true,
              onKeyEvent: (_, KeyEvent event) {
                events.add(event);
                return KeyEventResult.handled;
              },
              child: Container(),
            ),
          );
      
          await simulateKeyDownEvent(LogicalKeyboardKey.controlLeft);
      
          // This will fail when transit mode is KeyDataTransitMode.rawKeyData
          // because a down event for controlRight is synthesized.
          expect(events.length, 1);
      
          debugKeyEventSimulatorTransitModeOverride = null;
        });
      ```
      
      And the following this test is ok with `KeyDataTransitMode.rawKeyData` but rightly fails with `KeyDataTransitMode.keyDataThenRawKeyData`:
      
      ```dart
        testWidgets('Simulates consecutive key down events', (WidgetTester tester) async {
          debugKeyEventSimulatorTransitModeOverride = KeyDataTransitMode.rawKeyData;
      
          // Simulating several key down events without key up in between is tolerated
          // when transit mode is KeyDataTransitMode.rawKeyData, it will trigger an
          // assert on KeyDataTransitMode.keyDataThenRawKeyData.
          await simulateKeyDownEvent(LogicalKeyboardKey.arrowDown);
          await simulateKeyDownEvent(LogicalKeyboardKey.arrowDown);
      
          debugKeyEventSimulatorTransitModeOverride = null;
        });
      ```
      
      ## Related Issue
      
      Related to https://github.com/flutter/flutter/issues/143845
      
      ## Tests
      
      Adds two tests.
      8ade81fb
  2. 27 Feb, 2024 1 commit
  3. 23 Feb, 2024 1 commit
  4. 21 Feb, 2024 1 commit
    • auto-submit[bot]'s avatar
      Reverts "Changing `TextPainter.getOffsetForCaret` implementation to remove the... · f9b3b84d
      auto-submit[bot] authored
      Reverts "Changing `TextPainter.getOffsetForCaret` implementation to remove the logarithmic search (#143281)" (#143801)
      
      Reverts flutter/flutter#143281
      
      Initiated by: LongCatIsLooong
      
      Reason for reverting: https://github.com/flutter/flutter/issues/143797
      
      Original PR Author: LongCatIsLooong
      
      Reviewed By: {justinmc, jason-simmons}
      
      This change reverts the following previous change:
      Original Description:
      The behavior largely remains the same, except:
      
      1. The EOT cursor `(textLength, downstream)` for text ending in the opposite writing direction as the paragraph is now placed at the visual end of the last line. 
        For example, in a LTR paragraph, the EOT cursor for `aA` (lowercase for LTR and uppercase for RTL) is placed to the right of the line: `aA|` (it was `a|A` before). 
        This matches the behavior of most applications that do logical order arrow key navigation instead of visual order navigation. 
        And it makes the navigation order consistent for `aA\naA`:
      ```
        |aA    =>  aA|  => aA|  => aA  => aA   => aA 
         aA        aA      aA     |aA     aA|     aA|     
         (1)       (2)     (3)    (4)    (5)      (6)
      ```
      This is indeed still pretty confusing as (2) and (3), as well as (5) and (6) are hard to distinguish (when the I beam has a large width they are actually visually distinguishable -- they use the same anchor but one gets painted to the left and the other to the right. I noticed that emacs does the same). 
      But logical order navigation will always be confusing in bidi text, in one way or another.
      
      Interestingly there are 3 different behaviors I've observed in chrome:
      - the chrome download dialog (which I think uses GTK text widgets but not sure which version) gives me 2 cursors when navigating bidi text, and 
      - its HTML fields only show one, and presumably they place the I beam at the **trailing edge** of the character (which makes more sense for backspacing I guess). 
      - On the other hand, its (new) omnibar seems to use visual order arrow navigation
      
      Side note: we may need to update the "tap to place the caret here" logic to handle the case where the tap lands outside of the text and the text ends in the opposite writing direction. 
      
      2. Removed the logarithmic search. The same could be done using the characters package but when glyphInfo tells you about the baseline location in the future we probably don't need the `getBoxesForRange` call. This should fix https://github.com/flutter/flutter/issues/123424.
      
      ## Internal Tests
      
      This is going to change the image output of some internal golden tests. I'm planning to merge https://github.com/flutter/flutter/pull/143281 before this to avoid updating the same golden files twice for invalid selections.
      f9b3b84d
  5. 20 Feb, 2024 1 commit
    • LongCatIsLooong's avatar
      Changing `TextPainter.getOffsetForCaret` implementation to remove the logarithmic search (#143281) · 3538e4c7
      LongCatIsLooong authored
      The behavior largely remains the same, except:
      
      1. The EOT cursor `(textLength, downstream)` for text ending in the opposite writing direction as the paragraph is now placed at the visual end of the last line. 
        For example, in a LTR paragraph, the EOT cursor for `aA` (lowercase for LTR and uppercase for RTL) is placed to the right of the line: `aA|` (it was `a|A` before). 
        This matches the behavior of most applications that do logical order arrow key navigation instead of visual order navigation. 
        And it makes the navigation order consistent for `aA\naA`:
      ```
        |aA    =>  aA|  => aA|  => aA  => aA   => aA 
         aA        aA      aA     |aA     aA|     aA|     
         (1)       (2)     (3)    (4)    (5)      (6)
      ```
      This is indeed still pretty confusing as (2) and (3), as well as (5) and (6) are hard to distinguish (when the I beam has a large width they are actually visually distinguishable -- they use the same anchor but one gets painted to the left and the other to the right. I noticed that emacs does the same). 
      But logical order navigation will always be confusing in bidi text, in one way or another.
      
      Interestingly there are 3 different behaviors I've observed in chrome:
      - the chrome download dialog (which I think uses GTK text widgets but not sure which version) gives me 2 cursors when navigating bidi text, and 
      - its HTML fields only show one, and presumably they place the I beam at the **trailing edge** of the character (which makes more sense for backspacing I guess). 
      - On the other hand, its (new) omnibar seems to use visual order arrow navigation
      
      Side note: we may need to update the "tap to place the caret here" logic to handle the case where the tap lands outside of the text and the text ends in the opposite writing direction. 
      
      2. Removed the logarithmic search. The same could be done using the characters package but when glyphInfo tells you about the baseline location in the future we probably don't need the `getBoxesForRange` call. This should fix https://github.com/flutter/flutter/issues/123424.
      
      ## Internal Tests
      
      This is going to change the image output of some internal golden tests. I'm planning to merge https://github.com/flutter/flutter/pull/143281 before this to avoid updating the same golden files twice for invalid selections.
      3538e4c7
  6. 14 Feb, 2024 2 commits
  7. 13 Feb, 2024 1 commit
  8. 06 Feb, 2024 1 commit
    • Renzo Olivares's avatar
      TextField context menu should fade on scroll on mobile devices (#138313) · 0903bf70
      Renzo Olivares authored
      This change affects Android and iOS devices using the TextField's context menu. After this change the context menu will fade out when scrolling the text and fade in when the scroll ends. 
      
      If the scroll ends and the selection is outside of the view, then the toolbar will be scheduled to show in a future scroll end. This toolbar scheduling can be invalidated if the `TextEditingValue` changed anytime between the scheduling and when the toolbar is ready to be shown.
      
      This change also fixes a regression where the TextField context menu would not fade when the selection handles where not visible.
      
      When using the native browser context menu this behavior is not controlled by Flutter.
      
      https://github.com/flutter/flutter/assets/948037/3f46bcbb-ba6f-456c-8473-e42919b9d572
      
      Fixes #52425
      Fixes #105804
      Fixes #52426
      0903bf70
  9. 31 Jan, 2024 1 commit
  10. 30 Jan, 2024 1 commit
    • Renzo Olivares's avatar
      Fix: selection handles do not inherit color from local `Theme` widget (#142476) · 1daac1b8
      Renzo Olivares authored
      This change uses `CapturedTheme`s to capture the themes from the context the selection handles were built in and wraps the handles with them so they can correctly inherit `Theme`s from local `Theme` widgets.
      
      `CapturedTheme`s only captures `InheritedTheme`s, so this change also makes `_InheritedCupertinoTheme` an `InheritedTheme`. This is so we can capture themes declared under a `CupertinoTheme`, for example `primaryColor` is used as the selection handle color.
      
      Fixes #74890
      1daac1b8
  11. 24 Jan, 2024 1 commit
  12. 22 Jan, 2024 1 commit
    • Hassan Toor's avatar
      [web] - Fix broken `TextField` in semantics mode when it's a sibling of `Navigator` (#138446) · 59e892d3
      Hassan Toor authored
      When a `TextField` is rendered before a `Navigator`, it breaks in semantics mode.  This is because the framework generates the incorrect semantics tree (excludes the TextField) and when that tree gets sent to the engine, we don't get the signal to create the corresponding `<input>` element.
      
      This happens for a few reasons:
      * `ModalBarrier` uses `BlockSemantics` to drop the semantics of routes beneath the current route in `Navigator`
      * `ModalBarrier` mistakenly recognizes the widget outside of the `Navigator` to be its sibling
      *  So we end up dropping the semantics node of the `TextField` rendered before it. 
      
      The fix is to let `Navigator` generate a semantics node so that `ModalBarrier` doesn't mistakenly think widgets outside of `Navigator` are its siblings.  
      
      `Navigator` doesn't currently do this, which causes all the nodes generated from its widget subtree to be directly attached to the parent semantics node above `Navigator` - since this is also the parent of `TextField`, it considers them siblings. 
      
      Fixes https://github.com/flutter/flutter/issues/129324
      59e892d3
  13. 16 Jan, 2024 1 commit
  14. 12 Jan, 2024 1 commit
  15. 10 Jan, 2024 1 commit
  16. 03 Jan, 2024 1 commit
  17. 27 Dec, 2023 1 commit
  18. 21 Dec, 2023 1 commit
  19. 20 Dec, 2023 1 commit
  20. 15 Dec, 2023 2 commits
  21. 11 Dec, 2023 1 commit
  22. 08 Dec, 2023 1 commit
    • Bruno Leroux's avatar
      Add 'Share' button to the selection toolbar on Android (#139479) · e070417a
      Bruno Leroux authored
      ## Description
      
      This PR adds the 'Share' button to the text selection toolbar on Android.
      
      ## Related Issue
      
      Fixes https://github.com/flutter/flutter/issues/138728
      
      ## Tests
      
      Refactor a lot of existing tests in order to:
      - make them more readable (avoid duplication by introducing helper functions, specify explictly check which buttons are expected).
      - make them more accurate (check that expected buttons are visible instead of just checking the number of buttons).
      
      For instance, previous tests contained sections such as:
      
      ```dart
      
            // Collapsed toolbar shows 3 buttons.
            expect(
              find.byType(CupertinoButton),
              isContextMenuProvidedByPlatform ? findsNothing : isTargetPlatformIOS ? findsNWidgets(6) : findsNWidgets(3)
            );
      
      ```
      
      Where the comment is obsolete, the two cases (6 widgets and 3 widgets) are not explicit (which buttons are expected?), and not accurate (will pass if the number of buttons is right but the buttons are the wrong ones).
      e070417a
  23. 15 Nov, 2023 1 commit
  24. 11 Oct, 2023 1 commit
  25. 02 Oct, 2023 2 commits
  26. 22 Sep, 2023 1 commit
  27. 13 Sep, 2023 1 commit
  28. 08 Sep, 2023 1 commit
  29. 17 Aug, 2023 1 commit
  30. 16 Aug, 2023 1 commit
  31. 08 Aug, 2023 1 commit
  32. 07 Aug, 2023 1 commit
  33. 02 Aug, 2023 1 commit
  34. 06 Jul, 2023 1 commit
  35. 27 Jun, 2023 1 commit
  36. 15 May, 2023 1 commit
  37. 12 May, 2023 1 commit