1. 07 Feb, 2024 2 commits
  2. 01 Feb, 2024 1 commit
  3. 30 Jan, 2024 1 commit
  4. 26 Jan, 2024 3 commits
    • Michael Goderbauer's avatar
      Relands "Add runWidget to bootstrap a widget tree without a default View" (#142344) · 671d8eaf
      Michael Goderbauer authored
      Reverts flutter/flutter#142339
      
      In the original change one of the tests included the same view twice which resulted in a different failure than the expected one. The second commit contains the fix for this. I don't understand how this wasn't caught presubmit on CI.
      671d8eaf
    • auto-submit[bot]'s avatar
      Reverts "Add runWidget to bootstrap a widget tree without a default View" (#142339) · 114261a6
      auto-submit[bot] authored
      Reverts flutter/flutter#141484
      Initiated by: eliasyishak
      This change reverts the following previous change:
      Original Description:
      The existing `runApp` bootstraps the widget tree and renders the provided widget into the default view (which is currently the implicit View from `PlatformDispatcher.implicitView` and - in the future - may be a default-created window). Apps, that want more control over the View they are rendered in, need a new way to bootstrap the widget tree: `runWidget`. It does not make any assumptions about the View the provided widget is rendered into. Instead, it is up to the caller to include a View widget in the provided widget tree that specifies where content should be rendered. In the future, this may enable developers to create a custom window for their app instead of relying on the default-created one.
      114261a6
    • Michael Goderbauer's avatar
      Add runWidget to bootstrap a widget tree without a default View (#141484) · 5b44596c
      Michael Goderbauer authored
      The existing `runApp` bootstraps the widget tree and renders the provided widget into the default view (which is currently the implicit View from `PlatformDispatcher.implicitView` and - in the future - may be a default-created window). Apps, that want more control over the View they are rendered in, need a new way to bootstrap the widget tree: `runWidget`. It does not make any assumptions about the View the provided widget is rendered into. Instead, it is up to the caller to include a View widget in the provided widget tree that specifies where content should be rendered. In the future, this may enable developers to create a custom window for their app instead of relying on the default-created one.
      5b44596c
  5. 24 Jan, 2024 2 commits
  6. 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
  7. 19 Jan, 2024 2 commits
    • Michael Goderbauer's avatar
      Make pumpWidget's arguments named (#141728) · cc544169
      Michael Goderbauer authored
      Much nicer calling API and simplifies evolving this API in the future.
      
      I wish we could write a dart fix for this, but that's blocked on https://github.com/dart-lang/sdk/issues/54668.
      cc544169
    • fzyzcjy's avatar
      Tiny fix inaccurate documentations about bindings (#140282) · 9e024fdf
      fzyzcjy authored
      The old doc says that, AutomatedTestWidgetsFlutterBinding for `flutter test` and LiveTestWidgetsFlutterBinding for `flutter run`. However, suppose we `flutter test integration_test/simple_test.dart` with the following code:
      
      ```
      void main() {
        testWidgets('hi', (WidgetTester tester) async {
          print('hi ${TestWidgetsFlutterBinding.instance} ${Platform.operatingSystem}');
        });
      }
      ```
      
      We will see: `hi <IntegrationTestWidgetsFlutterBinding> ios`. Therefore, we see `IntegrationTestWidgetsFlutterBinding` is used in a `flutter test` command, which is contrary to the documentation.
      9e024fdf
  8. 16 Jan, 2024 1 commit
  9. 12 Jan, 2024 1 commit
  10. 10 Jan, 2024 2 commits
  11. 09 Jan, 2024 3 commits
    • Michael Goderbauer's avatar
      Reapply "Dynamic view sizing" (#140165) (#140918) · 4534a24c
      Michael Goderbauer authored
      This reverts commit
      https://github.com/flutter/flutter/commit/d24c01bd0c41331bd17165e0173b24c5d05d7c0a.
      
      The original change was reverted because it caused some apps to get
      stuck on the splash screen on some phones.
      
      An investigation determined that this was due to a rounding error.
      Example: The device reports a physical size of 1008.0 x 2198.0 with a
      dpr of 1.912500023841858. Flutter would translate that to a logical size
      of 527.0588169589221 x 1149.2810314243163 and use that as the input for
      its layout algorithm. Since the constraints here are tight, the layout
      algorithm would determine that the resulting logical size of the root
      render object must be 527.0588169589221 x 1149.2810314243163.
      Translating this back to physical pixels by applying the dpr resulted in
      a physical size of 1007.9999999999999 x 2198.0 for the frame. Android
      now rejected that frame because it didn't match the expected size of
      1008.0 x 2198.0 and since no frame had been rendered would never take
      down the splash screen.
      
      Prior to dynamically sized views, this wasn't an issue because we would
      hard-code the frame size to whatever the requested size was.
      
      Changes in this PR over the original PR:
      
      * The issue has been fixed now by constraining the calculated physical
      size to the input physical constraints which makes sure that we always
      end up with a size that is acceptable to the operating system.
      * The `ViewConfiguration` was refactored to use the slightly more
      convenient `BoxConstraints` over the `ViewConstraints` to represent
      constraints. Both essentially represent the same thing, but
      `BoxConstraints` are more powerful and we avoid a couple of translations
      between the two by translating the` ViewConstraints` from the
      `FlutterView` to `BoxConstraints` directly when the `ViewConfiguration`
      is created.
      
      All changes over the original PR are contained in the second commit of
      this PR.
      
      Fixes b/316813075
      Part of https://github.com/flutter/flutter/issues/134501.
      4534a24c
    • Polina Cherkasova's avatar
      Upgrade leak_tracker. (#141153) · 1f3103e5
      Polina Cherkasova authored
      1f3103e5
    • Polina Cherkasova's avatar
      188d4d1f
  12. 08 Jan, 2024 1 commit
  13. 04 Jan, 2024 1 commit
  14. 03 Jan, 2024 3 commits
  15. 02 Jan, 2024 1 commit
  16. 21 Dec, 2023 2 commits
  17. 20 Dec, 2023 5 commits
    • flutter-pub-roller-bot's avatar
      Roll pub packages (#140472) · 2d75f76b
      flutter-pub-roller-bot authored
      This PR was generated by `flutter update-packages --force-upgrade`.
      2d75f76b
    • Michael Goderbauer's avatar
      Remove outdated ignores from tool (#140467) · 68e346e4
      Michael Goderbauer authored
      These were not ignoring anything (anymore).
      68e346e4
    • LongCatIsLooong's avatar
      Reland `find.textRange.ofSubstring` changes (#140469) · e2e8bcb1
      LongCatIsLooong authored
      Extracted from https://github.com/flutter/flutter/pull/139717 as-is. Landing this change first so we can avoid doing a g3fix.
      e2e8bcb1
    • auto-submit[bot]'s avatar
      Reverts "Make `TextSpan` hit testing precise." (#140468) · 9003f138
      auto-submit[bot] authored
      Reverts flutter/flutter#139717
      Initiated by: LongCatIsLooong
      This change reverts the following previous change:
      Original Description:
      Fixes https://github.com/flutter/flutter/issues/131435, #104594, #43400
      Needs https://github.com/flutter/engine/pull/48774 (to fix the web test failure).
      
      Currently the method we use for text span hit testing `TextPainter.getPositionForOffset` always returns the closest `TextPosition`, even when the given offset is far away from the text. 
      
      The new TextPaintes method tells you the layout bounds (`width =  letterspacing / 2 + x_advance + letterspacing / 2`, `height = font ascent + font descent`) of a character, the PR changes the hit testing implementation such that a TextSpan is only considered hit if the point-down event landed in one of it's character's layout bounds.
      
      Potential issues:
      
      1. In theory since the text is baseline aligned, we should use the max ascent and max descent of each character to calculate the height of the text span's hit-test region, in case some characters in the span have to fall back to a different font, but that will be slower and it typically doesn't make a huge difference. 
      
      This is a breaking change. It also introduces a new finder and a new method `WidgetTester.tapOnText`: `await tester.tapOnText('string to match')` for ease of migration.
      9003f138
    • LongCatIsLooong's avatar
      Make `TextSpan` hit testing precise. (#139717) · ea5b9728
      LongCatIsLooong authored
      Fixes https://github.com/flutter/flutter/issues/131435, #104594, #43400
      Needs https://github.com/flutter/engine/pull/48774 (to fix the web test failure).
      
      Currently the method we use for text span hit testing `TextPainter.getPositionForOffset` always returns the closest `TextPosition`, even when the given offset is far away from the text. 
      
      The new TextPaintes method tells you the layout bounds (`width =  letterspacing / 2 + x_advance + letterspacing / 2`, `height = font ascent + font descent`) of a character, the PR changes the hit testing implementation such that a TextSpan is only considered hit if the point-down event landed in one of it's character's layout bounds.
      
      Potential issues:
      
      1. In theory since the text is baseline aligned, we should use the max ascent and max descent of each character to calculate the height of the text span's hit-test region, in case some characters in the span have to fall back to a different font, but that will be slower and it typically doesn't make a huge difference. 
      
      This is a breaking change. It also introduces a new finder and a new method `WidgetTester.tapOnText`: `await tester.tapOnText('string to match')` for ease of migration.
      ea5b9728
  18. 19 Dec, 2023 1 commit
  19. 16 Dec, 2023 1 commit
  20. 15 Dec, 2023 4 commits
  21. 14 Dec, 2023 1 commit
  22. 11 Dec, 2023 1 commit