Some upcoming engine changes will bind to a function provided by the emscripten JS wrapper around skwasm, rather than just the wasm module itself. This will make sure not to break the benchmarks when those engine changes land. See https://github.com/flutter/engine/pull/46388
Part of:
- https://github.com/flutter/flutter/issues/128251
Currently, when we want to use the analytics instance from `package:unified_analytics`, we are just grabbing it from globals. However, with the legacy analytics instance, there are some things we check to return a no-op version of the instance.. for example, if we are running on bots or a non standard branch, we use a no-op instance
This PR uses the same previous checks for the new analytics instance
* This is completely broken on the Impeller renderer, see: https://github.com/flutter/flutter/issues/135052
* Even on the Skia renderer, this gives a software rasterized screenshot which will absolutely look different from a native rendering screenshot.
I plan to remove this functionality from the engine.
This implements https://github.com/flutter/flutter/issues/132654#issuecomment-1738221257, namely:
Make `Chromium.close` more robust:
* Send `SIGTERM` and wait up to 5 seconds, if the process exited, great! Return from the function.
* If the process has not exited, then send a `SIGKILL`, which is a much firmer way to exit a process. Same as before, wait up to 5 seconds, if the process exited, great! Return from the function.
* If it still hasn't exited then give up trying to exit Chromium, just print a warning to the console and return from the function.
Bonus: a few nullability fixes and extra `-v` logging.
Fixes https://github.com/flutter/flutter/issues/132654
## Description
This PR updates `_TabBarViewState.didUpdateWidget` in order to react to `TabBarView.viewportFraction`change.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/135557.
## Tests
Adds 1 test.
Resolves#128046.
Adds a services API that allows flutter app developers to write app code that determines `--flavor` the app was built with.
This is implemented by having the tool adding the value of `--flavor` to its list of dart environment declarations, which will be available to the app at run time. Specifically,`FLUTTER_APP_FLAVOR` is set. I chose this implementation for its simplicity. There is some precedent for this, but only for web ([example](cd2f3f5e78/packages/flutter_tools/lib/src/runner/flutter_command.dart (L1231))).
This PR fixes#134846. As discussed in the issue, the onSubmitted callback of a TextField is called when the browser switches tabs or is sent to the background if the flutter app is running in any mobile browser (desktop browsers are not affected). Furthermore there is no straight forward way to distinguish between onSubmitted being called because the user pressed the enter key and it being called because the user switched tabs. For example in a chat app this would cause a message to be sent when the user submits the text by pressing "send" on the virtual keyboard as well as when the user switches to another tab. The later action is likely not so much intended.
The next section explains what causes the bug and explains the proposed fix.
## Bug Analysis
The root cause for this behaviour is line 3494 in editable_text.dart: 0b540a87f1/packages/flutter/lib/src/widgets/editable_text.dart (L3487-L3499)
Only if the app is running on the web `_finalizeEditing` is called and this will then trigger the onSubmitted callback. If flutter is running on the web, there are only exactly 3 cases, in which the function is called. The following call trace analysis will describe why.
- `connectionClosed()` is only called by in one location, `_handleTextInputInvocation` of the TextInput service.
367203b301/packages/flutter/lib/src/services/text_input.dart (L1896C12-L1899)
- In particular it is only called if the TextInput service receives a 'TextInputClient.onConnectionClosed' message from the engine.
- The only location where the web part of the engine send this message is the `onConnectionClosed` function of the TextEditingChannel.
cbda68a720/lib/web_ui/lib/src/engine/text_editing/text_editing.dart (L2242-L2254)
- `onConnectionClosed` in turn is only called by the `sendTextConnectionClosedToFrameworkIfAny` function of `HybridTextEditing`.
cbda68a720/lib/web_ui/lib/src/engine/text_editing/text_editing.dart (L2340-L2345)
The function `sendTextConnectionClosedToFrameworkIfAny` is only called at 3 distinct locations of the web engine.
### 1. IOSTextEditingStrategy
As described in the comment `sendTextConnectionClosedToFrameworkIfAny` is called if the browser is sent to the background or the tab is changed.
cbda68a720/lib/web_ui/lib/src/engine/text_editing/text_editing.dart (L1632-L1656)
### 2. AndroidTextEditingStrategy
Same situation as for iOS. `sendTextConnectionClosedToFrameworkIfAny` is also called if `windowHasFocus` is false, which is the case if the browser is sent to background or the tab is changed.
cbda68a720/lib/web_ui/lib/src/engine/text_editing/text_editing.dart (L1773-L1785)
### 3. TextInputFinishAutofillContext
This call seems to always happen when `finishAutofillContext` is triggered by the framework.
cbda68a720/lib/web_ui/lib/src/engine/text_editing/text_editing.dart (L2075-L2083)
## Proposed Fix
The fixed proposed and implemented by this PR is to simply delete the call to`_finalizeEditing` in the `connectionClosed` function of editable_text.dart.
0b540a87f1/packages/flutter/lib/src/widgets/editable_text.dart (L3487-L3499)
The reasoning for this being:
* `_finalizeEditing` is only called in `connectionClosed` for the web engine.
* As explained by the trace analysis above, the web engine only triggers this `_finalizeEditing` call in 3 cases.
* In the 2 cases for IOSTextEditingStrategy and AndroidTextEditingStrategy the web engine triggering the call only causes the undesired behaviour reported in the issue.
* In the third case for TextInputFinishAutofillContext, I can't see a good reason why this would require calling `_finalizeEditing` as it only instructs the platform to save the current values. Other platforms also don't have anything that would trigger onSubmitted being called, so it seems safe to remove it.
* For other platforms the onConnectionClosed function was recently incorporated to only unfocus the TextField. So removing the call `_finalizeEditing` unifies the platform behaviour. See also
https://github.com/flutter/flutter/pull/123929https://github.com/flutter/engine/pull/41500
*List which issues are fixed by this PR. You must list at least one issue.*
#134846
To simplify the evaluation, here are two versions of the minimal example given in the issue, build with the current master and with this PR applied:
current master: https://tauu.github.io/flutter-onsubmit-test/build/web-master/
current master + PR applied: https://tauu.github.io/flutter-onsubmit-test/build/web/
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.
