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
This is a tiny tweak to replace some top level if clauses with guard clauses in `FutureBuilder`. I find the resultant code much more readable, but this is a matter of taste and I didn't see any info one way or another on it in the style guide so let me know if this is not to your all's preference.
Support for FFI calls with `@Native external` functions through Native assets on Windows. This enables bundling native code without any build-system boilerplate code.
For more info see:
* https://github.com/flutter/flutter/issues/129757
### Implementation details for Windows.
Mainly follows the design of https://github.com/flutter/flutter/pull/134031.
Specifically for Windows in this PR is the logic for finding the compiler `cl.exe` and environment variables that contain the paths to the Windows headers `vcvars.bat` based on `vswhere.exe`.
Resolves#81831.
The PR improves the `config` command in below ways:
- Does not print the settings in usages or other options.
- Adds the `--list` flag to print the full settings list.
- Separates usages for settings and analytics.
- Prints the restart tip when clearing features.
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).
So there appears to be a race situation between the flutter CLI and Xcode. In the CLI, we update the `CONFIGURATION_BUILD_DIR` in the Xcode build settings and then tell Xcode to install, launch, and debug the app. When Xcode installs the app, it should use the `CONFIGURATION_BUILD_DIR` to find the bundle. However, it appears that sometimes Xcode hasn't processed the change to the build settings before the install happens, which causes it to not be able to find the bundle.
Fixes https://github.com/flutter/flutter/issues/135442
---
Since it's a timing issue, there's not really a consistent way to test it.
I was able to confirm that it works, though, by using the following steps:
1. Create a flutter project
2. Open the project in Xcode
3. `flutter clean`
4. `flutter run --profile -v`
If I saw a print line `stderr: CONFIGURATION_BUILD_DIR: build/Debug-iphoneos`, that means it first found the old and incorrect `CONFIGURATION_BUILD_DIR` before updating to the the new, so I was able to confirm that it would wait until it updated.
This measures the wall clock time between a new frame being scheduled in dart code to the Vsync callback in the engine
It's an important source of lag which isn't shown in the top-level UI / Build time graphs, and can correlate with "invisible" missed/non-scheduled frames
I had to change a few unrelated timings in the test, it was only passing based on luck of sort order, and broke when I added more entries to the timeline.
Part of #129150
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
PlatformViews have been supported without a custom engine build on iOS
for quite some time now, and are nearing support for macOS. Adds a link
to the website documentation covering creation of PlatformViews for iOS
and adds a TODO to do the same once the macOS PlatformView documentation
is ready.
Related: https://github.com/flutter/website/issues/9424
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
Reland of #134031. (Reverted in #135069.) Contains the fix for b/301051367 together with cl/567233346.
Support for FFI calls with `@Native external` functions through Native assets on Linux. This enables bundling native code without any build-system boilerplate code.
For more info see:
* https://github.com/flutter/flutter/issues/129757
### Implementation details for Linux.
Mainly follows the design of https://github.com/flutter/flutter/pull/130494.
Some differences are:
* Linux does not support cross compiling or compiling for multiple architectures, so this has not been implemented.
* Linux has no add2app.
The assets copying is done in the install-phase of the CMake build of a flutter app.
CMake requires the native assets folder to exist, so we create it also when the feature is disabled or there are no assets.
### Tests
This PR adds new tests to cover the various use cases.
* packages/flutter_tools/test/general.shard/linux/native_assets_test.dart
* Unit tests the Linux-specific part of building native assets.
It also extends various existing tests:
* packages/flutter_tools/test/integration.shard/native_assets_test.dart
* Runs (incl hot reload/hot restart), builds, builds frameworks for Linux and flutter-tester.
Removes an ignore about overriding fields. Instead we just assign the value to the original field in the super class.
Related to https://github.com/dart-lang/language/issues/3332 (discovered during investigations into the violation of that lint).
This analytics event only records the value of the plist entry on
`build` commands. This will give an idea of the proportion of users who
are disabling Impeller when shipping apps.
## 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.
When it comes to startup profiling, it is very helpful to look at platform channels. `debugProfilePlatformChannels` today only works in debug and profile mode. Unfortunately, using profile mode is less accurate for startup profiling, because of the service isolate introducing additional overhead.
This PR allows this toggle to work in release mode. Note that there are two parts to `debugProfilePlatformChannels`:
- Adding timeline events
- Logging statistics about platform channels
I also considered adding a separate toggle to limit the scope of this change to the former, but that seems like complexity that we might not need at this time.
Towards #102189
