This change collapses the selection at the clicked/tapped location on single click down for desktop platforms, and on single click/tap up for mobile platforms to match native.
This is a change from how `SelectionArea` previously worked. Before this change a single click down would clear the selection. From observing a native browser it looks like when tapping on static text the selection is not cleared but collapsed. A user can still attain the selection from static text using the `window.getSelection` API.
https://jsfiddle.net/juepasn3/11/ You can try this demo out here to observe this behavior yourself. When clicking on static text the selection will change.
This change also allows `Paragraph.selections` to return selections that are collapsed. This for testing purposes to confirm where the selection has been collapsed.
Partially fixes: #129583
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`.)
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).
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.
## 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
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
This PR adds a new option in the NavigationDrawerDestination api allowing it to be disabled, this is very useful for role based access control, especially in the navigation drawer which is used to lay out all the app destinations
* https://github.com/flutter/flutter/issues/132348
## Description
This PR adds a parameter to configure the input decorator hint fade transition duration.
This animation is not part of the Material specification.
Removing it was considered but it breaks internal tests (see https://github.com/flutter/flutter/pull/107406).
I also considered several ways to avoid the fade animation (setting duration to 0, removing the hint text, etc) but it breaks many existing tests that assumes the hint text to be visible.
To mitigate the issue in a non disruptive way, I set the default duration to 20ms (an arbitrary short value).
## Related Issue
Fixes https://github.com/flutter/flutter/issues/20283.
## Tests
Adds 3 tests, updates 3 tests.
## Description
This PR fixes form fields in order to call the `onChange` callback when the form is reset.
This change is based on the work done in https://github.com/flutter/flutter/pull/123108.
I considered adding the `onChange` callback to the `FormField` superclass but it would break existing code because two of the three subclasses defines the `onChange` callback with `ValueChanged<String>?` type and the third one defines it with `ValueChanged<String?>?`.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/123009.
## Tests
Adds 3 tests.
This PR modifies the web build slightly to create an `AssetManifest.json`, that is a JSON(base64)-encoded version of the `AssetManifest.bin` file.
_(This should enable all browsers to download the file without any interference, and all servers to serve it with the correct headers.)_
It also modifies Flutter's `AssetManifest` class so it loads and uses said file `if (kIsWeb)`.
### Issues
* Fixes https://github.com/flutter/flutter/issues/124883
### Tests
* Unit tests added.
* Some tests that run on the Web needed to be informed of the new filename, but their behavior didn't have to change (binary contents are the same across all platforms).
* I've deployed a test app, so users affected by the BIN issue may take a look at the PR in action:
* https://dit-tests.web.app
Reverts flutter/flutter#125927
context: b/300804374
Looks like a g3 fix might involve changing the names of widget on the customer app, and I am not sure if that would be the right approach forward. Putting up a revert to be safe for now.
## Description
This PR fixes `NavigationRail` hover position when text direction is set to RTL and `NavigationRail.extended` is true.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/134361.
## Tests
Adds 1 test.
