This PR properly resets the drag state when losing the gesture arena or when the recognizer stops tracking the current pointer. The _dragState enum was reset properly, but I had forgotten to also reset the `_start`, this caused an issue when the recognizer won the gesture arena the next time, as it tries to detect a drag given the old `_start` in `acceptGesture`, but the `_dragState` has been reset causing an assertion to trigger.
Notifies the engine when `PointerSignalEvents` have been ignored by the framework, through the `ui.PointerData.respond` method.
This allows the web to "preventDefault" (or not) on `wheel` events.
## Issues
* Fixes (partially): https://github.com/flutter/flutter/issues/139263
## Tests
* Added tests to ensure `respond` is called at the right time, with the right value.
## Demo
* https://dit-multiview-scroll.web.app
<details>
<summary>
## Previous versions
</summary>
1. Modified `PointerScrollEvent`, not shippable.
2. Modified when events were handled, instead of the opposite.
</details>
Currently on iOS `TextField` horizontal drag gestures will have precedence over parent horizontal drag gestures when competing with each other because the default `touchSlop` value used by `TextField` to calculate whether the threshold for a drag has been met is the same as the one used by parent horizontal drag gestures like `PageView`, and other `Scrollable`s. The default value is `18.0`, and because the `TextField` receives the `PointerEvent` first in this scenario, it always declares victory before any parent horizontal drag gestures has the chance to.
Native iOS behavior: The parent horizontal drag gestures will always win unless the drag originated on the cursor (collapsed selection), in that case the TextField cursor drag gestures will win.
This change:
* Introduces `BaseTapAndDragGestureRecognizer.eagerVictoryOnDrag` which can be used to configure the recognizer to declare victory immediately when it detects a drag, or when disabled it will wait until it is the last recognizer in the arena before declaring victory. The default behavior is that it declares victory immediately when the drag is detected.
* Eliminates the iOS cursor drag logic from `TextSelectionGestureDetector`, this logic is now delegated to the selection handle overlay which already had this logic in place.
* Enables iOS cursor to always beat other drag gestures by setting the touch slop lower.
* Disables `eagerVictoryOnDrag` for iOS to allow for parent drag gestures to win and match native behavior.
Fixes#124421, Fixes#130198, Fixes#142624, Fixes#142447, Fixes#127017
Fixes#38926
This patch implements the iOS behavior pointed out by @dkwingsmt at #38926 , which is also consistent with the performance of my settings application on the iPhone.
### iOS behavior (horizontal or vertical drag)
## Algorithm
When dragging: delta(combined) = max(i of n that are positive) delta(i) - max(i of n that are negative) delta(i)
It means that, if two fingers are moving +50 and +10 respectively, it will move +50; if they're moving at +50 and -10 respectively, it will move +40.
~~TODO~~
~~Write some test cases~~
I did not include the `'// flutter_ignore_for_file: stopwatch (see analyze.dart)'` directive since it's currently not used, and adding that shouldn't be too difficult.
Fixes#11884
As #38926 pointed out, the current Flutter implementation of multi-finger drag behavior is different from iOS and Android.
This change introduces the `MultitouchDragStrategy` attribute, which implements the Android behavior and can be controlled through `ScrollBehavior`, while retaining the ability to extend iOS behavior in the future.
This PR adds the ability to get the `sourceTimeStamp` from `ScaleUpdateDetails` in a `GestureScaleUpdateCallback` like so:
```dart
onScaleUpdate: (ScaleUpdateDetails details){
print(details.sourceTimeStamp);
}
```
`sourceTimeStamp` is necessary when tracking velocity eg.
```dart
VelocityTracker tracker = VelocityTracker.withKind(PointerDeviceKind.touch);
///...
onScaleUpdate: (ScaleUpdateDetails details){
tracker.addPosition(details.sourceTimeStamp!, details.focalPoint);
}
```
The docs say:
>Having both a pan gesture recognizer and a scale gesture recognizer is redundant; scale is a superset of pan. Just use the scale gesture recognizer.
Currently this is not entirely accurate, and should be fixed, as noted in https://github.com/flutter/flutter/issues/43833#issuecomment-548133779. This PR does not add `sourceTimeStamp` to `ScaleStartDetails` because it is more involved. Specifically, `ScaleStartDetails` can be created in `acceptGesture` which does not have access to the `PointerEvent` to get the `event.timeStamp` (54fa255432/packages/flutter/lib/src/gestures/scale.dart (L730C5-L730C5)).
fixes https://github.com/flutter/flutter/issues/135873. See also https://github.com/flutter/flutter/issues/43833 which added delta and https://github.com/flutter/flutter/issues/49025 which added `numPointers` to `ScaleUpdateDetails` for the reason given above. `sourceTimeStamp` should probably be added to `ScaleStartDetails` as well because it exists in `DragStartDetails` and therefore in `onPanStart`.
I am not sure how to add tests for this, any input about this PR would be appreciated.
- [] All existing and new tests are passing.
This updates the implementation to use the stopwatch from the Clock object and pipes it through to the TestWidgetsFlutterBinding so it will be kept in sync with FakeAsync.
Relands https://github.com/flutter/flutter/pull/138843 attempted to reland https://github.com/flutter/flutter/pull/137381 which attempted to reland #132291
Fixes https://github.com/flutter/flutter/issues/97761
1. The original change was reverted due to flakiness it introduced in tests that use fling gestures.
* Using a mocked clock through the test binding fixes this now
2. It was reverted a second time because a change at tip of tree broke it, exposing memory leaks, but it was not rebased before landing.
* These leaks are now fixed
3. It was reverted a third time, because we were so excellently quick to revert those other times, that we did not notice the broken benchmark that only runs in postsubmit.
* The benchmark is now fixed
Reverts flutter/flutter#137381
Initiated by: Piinks
This change reverts the following previous change:
Original Description:
This updates the implementation to use the stopwatch from the Clock object and piping it through to the TestWidgetsFlutterBinding so it will be kept in sync with FakeAsync.
Relands #132291
Fixes https://github.com/flutter/flutter/issues/97761
The change was reverted due to flakiness it introduced in tests that use fling gestures.
* https://github.com/flutter/flutter/issues/135728
Before this change, long-running post-frame callbacks wouldn't show up in the timeline at all. This adds a timeline event for post-frame callbacks, with a debug flag that will add timeline events for each individual callback.
#testexempt -- we have no way to test calls to the timeline.
## Issue
**Issue:** https://github.com/flutter/flutter/issues/97761https://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
## Description
Fix three memory leaks detected by `about_test.dart`, but were really in the `Route` and `OverlayEntry` classes.
## Related Issues
- Fixes https://github.com/flutter/flutter/issues/130354
## Tests
- Updates about_test.dart to not ignore the leaks anymore.
Previously, if you changed buttons during a long-press gesture, if it was before the gesture was accepted we would discard it, and if it was after the gesture was accepted we would silently end it without firing any of the relevant events.
This silent cancelation behavior is terrible because it means there's no way for consumers to know what state they're in, so you end up with widgets that thing they're still being long-pressed even though nothing is happening.
We could change the behavior in three ways, as far as I can tell:
- we could send a cancel event when you change buttons. This would introduce a new kind of transition (start->cancel) which I don't think we currently require people to support. This would therefore not fix existing code and would make future code more complicated to handle a really obscure user action that it seems unlikely anyone cares about.
- we could send an end event when you change buttons. This would mean the action commits, even though the user is still holding the mouse button down. This seems slightly better than the previous option but still not ideal as it means nudging the mouse button commits you even though you're still holding the button down.
- we could ignore button changes after the long-press has been accepted.
I implemented the last one in this PR.
This fixes an issue where the bottom sheet would rebuild when `enableDrag` is set to true on every tap. This is because `DragGestureRecognizer` would win the arena by default and dispatch the `drag` callbacks (in `acceptGesture`) even though it had not met the drag threshold. This changes keep the default behavior of `DragGestureRecognizer` the same, but adds a parameter `onlyAcceptDragOnThreshold` that a user can use to stop drag callbacks from being fired when the drag threshold has not been met.
Fixes#126833
* Revert "Remove references to BindingBase.window (#122119)"
This reverts commit c7681f00cf1fb1c63bebb27d715f29feb77b78b7.
* Revert "Remove another reference to BindingBase.window (#122341)"
This reverts commit 6ec444506375cfa94535a45c2320e01094c295e0.
* Revert "Reland (2): Removes single window assumptions from `flutter_test` (#122233)"
This reverts commit eb3d317ea06e59fadc379210f5c6e685505d8e0f.
* Revert "Remove single view assumption from TestViewConfiguration (#122352)"
This reverts commit 927289fb4e5b25a71f794bc808a8c31554859a50.
* Revert "Updates `flutter/test/cupertino` to no longer use `TestWindow` (#122325)"
This reverts commit 67e17e45f05271c6c409183c1d33806683cb9e4d.
* Revert "Updates `flutter/test/gestures` to no longer reference `TestWindow` (#122327)"
This reverts commit c2a5111cc0f9bcb104982b38a1a0a9c4210b601f.
* Revert "Updates `flutter/test/rendering` to no longer use `TestWindow` (#122347)"
This reverts commit 28b65e089b3f8e8c21572cd8a73184858b6360c3.
* Revert "Updates `flutter_localizations/test` to stop using `TestWindow` (#122321)"
This reverts commit 01367d52d7886f51a8921c9dc4a8e4c541686e98.
