## What's new?
- While coming up with a scheme for testing multi-window, I realize that
issuing taps in `testWidgets` across views was not working because the
view was always being set to `0`
- The fix is to resolve the view when we can, and provide an optional
view in the other methods
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
This auto-formats all *.dart files in the repository outside of the
`engine` subdirectory and enforces that these files stay formatted with
a presubmit check.
**Reviewers:** Please carefully review all the commits except for the
one titled "formatted". The "formatted" commit was auto-generated by
running `dev/tools/format.sh -a -f`. The other commits were hand-crafted
to prepare the repo for the formatting change. I recommend reviewing the
commits one-by-one via the "Commits" tab and avoiding Github's "Files
changed" tab as it will likely slow down your browser because of the
size of this PR.
---------
Co-authored-by: Kate Lovett <katelovett@google.com>
Co-authored-by: LongCatIsLooong <31859944+LongCatIsLooong@users.noreply.github.com>
When running `dart format` over these lines the `// ignore` ended up on
a line where it wasn't properly ignoring the lint. This adjusts the
placement of `// ignore`s so they will continue to ignore the right
thing even after the code is auto formatted.
I am hoping that if we do this now the large PR that formats the entire
repo will go in smoother without manual intervention.
Hopefully soon, [flutter.dev/go/dart-patterns](https://flutter.dev/go/dart-patterns) will have lots of good feedback; in the meantime, I'll focus refactoring efforts on uncontroversial things :)
Previously, I was under the impression that I could solve issue #143803 with [just 1 PR](https://github.com/flutter/flutter/pull/143804).
It turns out that I had overlooked quite a bit!
<br>
```dart
// before
if (chunkEvents != null) {
chunkEvents.listen((ImageChunkEvent event) {
reportImageChunkEvent(event);
},
);
}
// after
chunkEvents?.listen(reportImageChunkEvent);
```
Resolves#151446
`DragGestureRecognizer` defines several private abstract methods that are implemented by its subclasses.
In the **super_editor** package, we'd like to extend `PanGestureRecognizer` to make it more aggressive, so it can win the gesture arena when placed inside a `CustomScrollview`. However, since we can't override private methods, tweaking this single function would involve copying the entire `DragGestureRecognizer` interface and its `PanGestureRecognizer` implementation.
<br>
Methods that were updated in this PR:
| Method | Rationale |
|---|---|
| `_hasSufficientGlobalDistanceToAccept` | This is the most important method for us. Overriding this method allows tweaking the PanGestureRecognizer to be more aggressive. |
| `_considerFling` | In **super_editor** we use the PanGestureRecognizer, but we want the fling gesture to behave as if it was a VerticalDragRecognizer. We'll use the fling gesture just to scroll vertically. |
| `_finalPosition` | I added a getter to be able to access it inside `_considerFling`. |
| `_globalDistanceMoved` | I added a getter to be able to access it inside `_hasSufficientGlobalDistanceToAccept`. |
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.
