1. 03 Oct, 2023 1 commit
  2. 02 Oct, 2023 6 commits
  3. 01 Oct, 2023 2 commits
  4. 30 Sep, 2023 2 commits
  5. 29 Sep, 2023 3 commits
  6. 28 Sep, 2023 7 commits
  7. 27 Sep, 2023 2 commits
  8. 26 Sep, 2023 2 commits
    • Kate Lovett's avatar
      Allow multiple ParentDataWidgets to write to ParentData (#133581) · 67d4a831
      Kate Lovett authored
      Fixes https://github.com/flutter/flutter/issues/133089
      
      This allows more than one ParentDataWidget to write to the ParentData of a child render object. Previously only one was allowed. There are some rules though:
      1. Only one of a given type of `ParentDataWidget` can write to the `ParentData` of a given child.
        a. For example, 2 `Positioned` widgets wrapping a child of a `Stack` would not be allowed, as only one of type `Positioned` can contribute data.
      
      2. The type of `ParentData` **must** be compatible with all of the `ParentDataWidget`s that want to contribute data.
        a. For example, `TwoDimensionalViewportParentData` mixes in the `KeepAliveParentDataMixin`. So the `ParentData` of a given child would be compatible with the `KeepAlive` `ParentDataWidget`, as well as another `ParentDataWidget` that writes `TwoDimensionalViewportParentData` (or a subclass of `TwoDimensionalViewportParentData` - This was the motivation for this change, where a `ParentDataWidget` is being used in `TableView` with the parent data type being a subclass of `TwoDimensionalViewportParentData`.)
      67d4a831
    • Renzo Olivares's avatar
      SelectionArea long press selection overlay behavior should match native (#133967) · d81c8aa8
      Renzo Olivares authored
      During a long press, on native iOS the context menu does not show until the long press has ended. The handles are shown immediately when the long press begins. This is true for static and editable text.
      
      For static text on Android, the context menu appears when the long press is initiated, but the handles do not appear until the long press has ended. For editable text on Android, the context menu does not appear until the long press ended, and the handles also do not appear until the end.
      
      For both platforms in editable/static contexts the context menu does not show while doing a long press drag.
      
      I think the behavior where the context menu is not shown until the long press ends makes the most sense even though Android varies in this depending on the context. The user is not able to react to the context menu until the long press has ended.
      
      Other details:
      On a windows touch screen device the context menu does not show up until the long press ends in editable/static text contexts. On a long press hold it selects the word on drag start as well as popping up the selection handles (static text).
      d81c8aa8
  9. 25 Sep, 2023 4 commits
    • Edgar Jan's avatar
      Fix and Test Conditional Validator Behavior in FormField (#132714) · 79caa837
      Edgar Jan authored
      In the FormField widget, if a validator is initially set (and validation fails), then subsequently the validator is set to null, the form incorrectly retains its error state. This is not expected behavior as removing the validator should clear any validation errors.
      79caa837
    • Chip Weinberger's avatar
      [Velocity Tracker] Fix: Issue 97761: Flutter Scrolling does not match iOS;... · fffbbf27
      Chip Weinberger authored
      [Velocity Tracker] Fix: Issue 97761: Flutter Scrolling does not match iOS; inadvertent scrolling when user lifts up finger (#132291)
      
      ## Issue
      
      **Issue:** https://github.com/flutter/flutter/issues/97761
      
      https://github.com/flutter/flutter/assets/1863934/53c5e0df-b85a-483c-a17d-bddd18db3aa9
      
      ## The Cause:
      
      The bug is very simple to understand - `velocity_tracker.dart` **only adds new samples while your finger is moving**.
      
      **Therefore**, if you move your finger quickly & (important) stop suddenly with no extra movement, the last 3 samples will all be > 0 dy. Regardless of how long you wait, you will get movement when you lift up your finger.
      
      **Logs from velocity_tracker.dart:**
      Notice: all 3 `_previousVelocityAt` are `dy > 0` despite a 2 second delay since the last scroll
      ```
      // start moving finger
      flutter: addPosition dy:-464.0
      flutter: addPosition dy:-465.0
      flutter: addPosition dy:-466.0
      flutter: addPosition dy:-467.0
      flutter: addPosition dy:-468.0
      flutter: addPosition dy:-469.0
      flutter: addPosition dy:-470.0
      // stop moving finger here, keep it still for 2 seconds & lift it up
      flutter: _previousVelocityAt(-2) samples(-467.0, -468.0)) dy:-176.772140710624
      flutter: _previousVelocityAt(-1) samples(-468.0, -469.0)) dy:-375.0937734433609
      flutter: _previousVelocityAt(0) samples(-469.0, -470.0)) dy:-175.71604287471447
      flutter: primaryVelocity DragEndDetails(Velocity(0.0, -305.5)).primaryVelocity
      flutter: createBallisticSimulation pixels 464.16666666666663 velocity 305.4699824197211
      ```
      
      ## The Fix
      
      **There are 3 options to fix it:**
      A. sample uniformly *per unit time* (a larger more risky change, hurts battery life)
      B. consider elapsed time since the last sample. If greater than X, assume no more velocity. (easy & just as valid)
      C. similar to B, but instead add "ghost samples" of velocity zero, and run calculations as normal (a bit tricker, of dubious benefit imo)
      
      **For Option B I considered two approaches:**
      1. _get the current timestamp and compare to event timestamp._  This is tricky because events are documented to use an arbitrary timescale & I wasn't able to find the code that generates the timestamps. This approach could be considered more.
      2. _get a new timestamp using Stopwatch and compare now vs when the last sample was added._ This is the solution implemented here.  There is a limitation in that we don't know when addSamples is called relative to the event. But, this estimation is already on a very low latency path & still it gives us a *minimum* time bound which is sufficient for comparison. 
      
      **This PR chooses the simplest of the all solutions. Please try it our yourself, it completely solves the problem 😀** Option _B.1_ would be a nice alternative as well, if we can define and access the same timesource as the pointer tracker in a maintainable simple way.
      
      ## After Fix
      
      https://github.com/flutter/flutter/assets/1863934/be50d8e7-d5da-495a-a4af-c71bc541cbe3
      fffbbf27
    • LongCatIsLooong's avatar
      Add a basic golden test for `CupertinoTextSelectionToolbar` (#135267) · 6a9df55d
      LongCatIsLooong authored
      Goden tests are easier to understand than `paints..` since the toolbar has a relatively complex path, and this should make PRs that make visual changes easier to review. 
      
      The current goldens don't look correct since I messed up the y offset of the tip of the arrow when the arrow is pointing up. Should be fixed in https://github.com/flutter/flutter/pull/133386
      6a9df55d
    • Polina Cherkasova's avatar
      49f1a6bb
  10. 22 Sep, 2023 6 commits
  11. 21 Sep, 2023 5 commits