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~~
This makes several changes to flutter web app bootstrapping.
* The build now produces a `flutter_bootstrap.js` file.
* By default, this file does the basic streamlined startup of a flutter app with the service worker settings and no user configuration.
* The user can also put a `flutter_bootstrap.js` file in the `web` subdirectory in the project directory which can have whatever custom bootstrapping logic they'd like to write instead. This file is also templated, and can use any of the tokens that can be used with the `index.html` (with the exception of `{{flutter_bootstrap_js}}`, see below).
* Introduced a few new templating tokens for `index.html`:
* `{{flutter_js}}` => inlines the entirety of `flutter.js`
* `{{flutter_service_worker_version}}` => replaced directly by the service worker version. This can be used instead of the script that sets the `serviceWorkerVersion` local variable that we used to have by default.
* `{{flutter_bootstrap_js}}` => inlines the entirety of `flutter_bootstrap.js` (this token obviously doesn't apply to `flutter_bootstrap.js` itself).
* Changed `IndexHtml` to be called `WebTemplate` instead, since it is used for more than just the index.html now.
* We now emit warnings at build time for certain deprecated flows:
* Warn on the old service worker version pattern (i.e.`(const|var) serviceWorkerVersion = null`) and recommends using `{{flutter_service_worker_version}}` token instead
* Warn on use of `FlutterLoader.loadEntrypoint` and recommend using `FlutterLoader.load` instead
* Warn on manual loading of `flutter_service_worker.js`.
* The default `index.html` on `flutter create` now uses an async script tag with `flutter_bootstrap.js`.
Some tests are assuming the flutter sdk code is being checked out to flutter and checking the code to a different repository makes them fail.
Bug: https://github.com/flutter/flutter/issues/144487
Reverts: flutter/flutter#144706
Initiated by: gspencergoog
Reason for reverting: This has broken the tree because some tests are still failing post completion. This particular one looks like it might have to do with a gold image not existing.
Original PR Author: goderbauer
Reviewed By: {Piinks}
This change reverts the following previous change:
A test was failing silently because of this (see https://github.com/flutter/flutter/issues/144353 and fixed in https://github.com/flutter/flutter/pull/144709). The failure went undetected for months. Ideally, this should have been a regular non-silent failure. This change makes that so. `package:test` can properly handle reported exceptions outside of test cases. With this change, the test fails as follows:
```
00:03 +82: Smoke test material/color_scheme/dynamic_content_color.0.dart
══╡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK ╞════════════════════════════════════════════════════
The following assertion was thrown running a test (but after the test had completed):
setState() called after dispose(): _DynamicColorExampleState#1cd37(lifecycle state: defunct, not
mounted)
This error happens if you call setState() on a State object for a widget that no longer appears in
the widget tree (e.g., whose parent widget no longer includes the widget in its build). This error
can occur when code calls setState() from a timer or an animation callback.
The preferred solution is to cancel the timer or stop listening to the animation in the dispose()
callback. Another solution is to check the "mounted" property of this object before calling
setState() to ensure the object is still in the tree.
This error might indicate a memory leak if setState() is being called because another object is
retaining a reference to this State object after it has been removed from the tree. To avoid memory
leaks, consider breaking the reference to this object during dispose().
When the exception was thrown, this was the stack:
#0 State.setState.<anonymous closure> (package:flutter/src/widgets/framework.dart:1167:9)
#1 State.setState (package:flutter/src/widgets/framework.dart:1202:6)
#2 _DynamicColorExampleState._updateImage (package:flutter_api_samples/material/color_scheme/dynamic_content_color.0.dart:191:5)
<asynchronous suspension>
════════════════════════════════════════════════════════════════════════════════════════════════════
00:03 +81 -1: Smoke test material/context_menu/context_menu_controller.0.dart
00:03 +81 -1: Smoke test material/color_scheme/dynamic_content_color.0.dart [E]
Test failed. See exception logs above.
The test description was: Smoke test material/color_scheme/dynamic_content_color.0.dart
This test failed after it had already completed.
Make sure to use a matching library which informs the test runner
of pending async work.
```
A test was failing silently because of this (see
https://github.com/flutter/flutter/issues/144353 and fixed in
https://github.com/flutter/flutter/pull/144709). The failure went
undetected for months. Ideally, this should have been a regular
non-silent failure. This change makes that so. `package:test` can
properly handle reported exceptions outside of test cases. With this
change, the test fails as follows:
```
00:03 +82: Smoke test material/color_scheme/dynamic_content_color.0.dart
══╡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK ╞════════════════════════════════════════════════════
The following assertion was thrown running a test (but after the test had completed):
setState() called after dispose(): _DynamicColorExampleState#1cd37(lifecycle state: defunct, not
mounted)
This error happens if you call setState() on a State object for a widget that no longer appears in
the widget tree (e.g., whose parent widget no longer includes the widget in its build). This error
can occur when code calls setState() from a timer or an animation callback.
The preferred solution is to cancel the timer or stop listening to the animation in the dispose()
callback. Another solution is to check the "mounted" property of this object before calling
setState() to ensure the object is still in the tree.
This error might indicate a memory leak if setState() is being called because another object is
retaining a reference to this State object after it has been removed from the tree. To avoid memory
leaks, consider breaking the reference to this object during dispose().
When the exception was thrown, this was the stack:
#0 State.setState.<anonymous closure> (package:flutter/src/widgets/framework.dart:1167:9)
#1 State.setState (package:flutter/src/widgets/framework.dart:1202:6)
#2 _DynamicColorExampleState._updateImage (package:flutter_api_samples/material/color_scheme/dynamic_content_color.0.dart:191:5)
<asynchronous suspension>
════════════════════════════════════════════════════════════════════════════════════════════════════
00:03 +81 -1: Smoke test material/context_menu/context_menu_controller.0.dart
00:03 +81 -1: Smoke test material/color_scheme/dynamic_content_color.0.dart [E]
Test failed. See exception logs above.
The test description was: Smoke test material/color_scheme/dynamic_content_color.0.dart
This test failed after it had already completed.
Make sure to use a matching library which informs the test runner
of pending async work.
```
Reverts: flutter/flutter#144752
Initiated by: andrewkolos
Reason for reverting: compilation issue has turned the tree red
Original PR Author: andrewkolos
Reviewed By: {christopherfujino}
This change reverts the following previous change:
In service of https://github.com/flutter/flutter/issues/143348
When invoking a package to transform an asset, we set `FLUTTER_BUILD_MODE` to the CLI name of the build mode being used. Inspired by https://github.com/flutter/flutter/issues/101077#issuecomment-1890379501:
> Do transformers know whether they get executed in debug or release mode? I kinda imagine that being useful. Ex: There's a transformer that optimizes the file size of images. Depending on the amount and size of the images, that could take a significant amount of time. Therefore, I might want to only execute it in release builds.
Note for the reviewer: the interesting part of this change can be found in the commit [set environment variable to build mode when running asset transformer…](579912d470). The rest of the change is updating call sites with a new argument.
In service of https://github.com/flutter/flutter/issues/143348
When invoking a package to transform an asset, we set `FLUTTER_BUILD_MODE` to the CLI name of the build mode being used. Inspired by https://github.com/flutter/flutter/issues/101077#issuecomment-1890379501:
> Do transformers know whether they get executed in debug or release mode? I kinda imagine that being useful. Ex: There's a transformer that optimizes the file size of images. Depending on the amount and size of the images, that could take a significant amount of time. Therefore, I might want to only execute it in release builds.
Note for the reviewer: the interesting part of this change can be found in the commit [set environment variable to build mode when running asset transformerâ¦](579912d470). The rest of the change is updating call sites with a new argument.
The purpose of this PR is to temporarily skip one integration test that is blocking the changes indicated below:
(This change adds a new property in Semantics widget that would take an integer corresponding to the heading levels defined by the ARIA heading role. This is necessary in order to get proper accessibility and usability in a website for users who rely on screen readers and other assistive technologies.)
Issue fixed by this PR:
https://github.com/flutter/flutter/issues/97894
Engine part:
https://github.com/flutter/engine/pull/41435
Framework part:
https://github.com/flutter/flutter/pull/125771
This is part 4 of a broken down version of the #140101 refactor.
This PR renames isAvailableForEnvironment to isForEnvironment and replaces a regular expression with a simple function. (The latter will change the behaviour for people with branch names like `mainly_refactors` or `chess_master_experiment` or whatever, but I'm pretty sure the old behaviour was not intended.)
----
This is a reland of https://github.com/flutter/flutter/pull/143176 which was speculatively reverted in https://github.com/flutter/flutter/pull/144855 but turned out not to be the cause of the tree redness.
Reverts: flutter/flutter#143176
Initiated by: QuncCccccc
Reason for reverting: made tree red.
Original PR Author: Hixie
Reviewed By: {Piinks}
This change reverts the following previous change:
This is part 4 of a broken down version of the #140101 refactor.
This PR renames isAvailableForEnvironment to isForEnvironment and replaces a regular expression with a simple function. (The latter will change the behaviour for people with branch names like `mainly_refactors` or `chess_master_experiment` or whatever, but I'm pretty sure the old behaviour was not intended.)
This is part 4 of a broken down version of the #140101 refactor.
This PR renames isAvailableForEnvironment to isForEnvironment and replaces a regular expression with a simple function. (The latter will change the behaviour for people with branch names like `mainly_refactors` or `chess_master_experiment` or whatever, but I'm pretty sure the old behaviour was not intended.)
Fixes#124850.
Changes the fallback for the builder on Android. Before the error was from the platform being changed mid Cupertino transition to iOS. If a default builder wasn't set for iOS (which a developer developing only for Android might not), then it defaulted to the Zoom transition. Which changing the transition while on the fly caused issues.
This fixes https://github.com/flutter/flutter/issues/143703
We need to make sure that when source maps are enabled for the dart2js target, it advertises the sourcemap file as one of its outputs so that the web release bundle can copy it over.
The flutter engine & framework can opt out of this optimization for
individual classes / class hierarchies via:
* `@pragma(flutter:keep-to-string)`
* `@pragma(flutter:keep-to-string-in-subtypes)`
Or by using the convenience constant `@keepToString` from `dart:ui`.
=> This aligns the build process more with g3 (which already does this)
Closes https://github.com/flutter/flutter/issues/52759
## Update `AlertDialog` Documentation for Material 3 Defaults
This pull request updates the documentation for `AlertDialog` to accurately reflect the default text styles (`titleTextStyle` and `contentTextStyle`) when using Material 3.
Previously, the documentation suggested default styles (`TextTheme.titleLarge` for titles and `TextTheme.titleMedium` for content) that do not align with Material 3 implementation, which uses `TextTheme.headlineSmall` and `TextTheme.bodyMedium` respectively.
Fixes#144489
Part of #137040 and #80374
The flag `throwOnPluginPubspecError` never actually was enabled during production in #79669, but only in some dart plugin tests. And in the tests the case of the error when enabling the flag was not explicitly tested. The only thing tested was, that it is not thrown when disabled.
As explained [here](https://github.com/flutter/flutter/pull/142035#discussion_r1484237904) the only case, where this error could be thrown is, when a dart implementation and a native inline implementation are provided simultaneously. But throwing an exception there is a wrong behavior, as both can coexist in a plugin package, thus in the pubspec file.
Disabling the flag means, that the error is not thrown and not shown to the user. This is the case in production (contrary to the dart plugin tests), which acts like these plugin cases of implementations are just skipped. And this is what actually should be done.
In conclusion, I think the case of coexisting dart and native implementation in pubspec was just overlooked and therefore this error validation was introduced, which is not necessary or even valid.
For more discussion, see: https://discord.com/channels/608014603317936148/608022056616853515/1200194937791205436
- This is tricky: I already added a test in #142035, which finally complies with the other tests, by removing the flag. So I think it falls in the category of "remove dead code".
- Theoretically this is a breaking change, as removing / altering some tests. But the flag actually was never valid or used, so IDK. But this may not does fall in the category of "contributed tests".
## Description
This PRs changes the default value for the `platform` parameter used to simulate key events.
With this PR, the default value is "web" on web, otherwise it is the operating system name retrieved from `defaultTargetPlatform`.
Previously, for methods in `WidgetController`, it defaulted to âwebâ on web, and âandroidâ everywhere else. And for methods in `KeyEventSimulator` it defaulted to âwebâ on web, and the operating system that the test was running on everywhere else. Because the operating system was based on `Platform.operatingSystem`, it usually differed from the target platform the test was running on.
AFAIK, the `platform` parameter is only meaningful for simulating `RawKeyEvent`. Once `RawKeyboard` will be fully removed, the `platform` parameter wonât be needed.
@gspencergoog In the meantime, do you think it is worth merging this fix?
## Related Issue
Fixes to https://github.com/flutter/flutter/issues/133955
## Tests
Adds one test.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.*
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
## Description
This PRs changes the default value transit mode for key event simulation.
The default transit mode for key event simulation is currently `KeyDataTransitMode.rawKeyData` while on the framework side `KeyDataTransitMode.keyDataThenRawKeyData` is the preferred transit mode.
`KeyDataTransitMode.keyDataThenRawKeyData` is more accurate and can help detect issues.
For instance the following test will fail with `KeyDataTransitMode.rawKeyData` because raw keyboard logic for modifier keys is less accurate:
```dart
testWidgets('Press control left once', (WidgetTester tester) async {
debugKeyEventSimulatorTransitModeOverride = KeyDataTransitMode.keyDataThenRawKeyData;
final List<KeyEvent> events = <KeyEvent>[];
final FocusNode focusNode = FocusNode();
addTearDown(focusNode.dispose);
await tester.pumpWidget(
Focus(
focusNode: focusNode,
autofocus: true,
onKeyEvent: (_, KeyEvent event) {
events.add(event);
return KeyEventResult.handled;
},
child: Container(),
),
);
await simulateKeyDownEvent(LogicalKeyboardKey.controlLeft);
// This will fail when transit mode is KeyDataTransitMode.rawKeyData
// because a down event for controlRight is synthesized.
expect(events.length, 1);
debugKeyEventSimulatorTransitModeOverride = null;
});
```
And the following this test is ok with `KeyDataTransitMode.rawKeyData` but rightly fails with `KeyDataTransitMode.keyDataThenRawKeyData`:
```dart
testWidgets('Simulates consecutive key down events', (WidgetTester tester) async {
debugKeyEventSimulatorTransitModeOverride = KeyDataTransitMode.rawKeyData;
// Simulating several key down events without key up in between is tolerated
// when transit mode is KeyDataTransitMode.rawKeyData, it will trigger an
// assert on KeyDataTransitMode.keyDataThenRawKeyData.
await simulateKeyDownEvent(LogicalKeyboardKey.arrowDown);
await simulateKeyDownEvent(LogicalKeyboardKey.arrowDown);
debugKeyEventSimulatorTransitModeOverride = null;
});
```
## Related Issue
Related to https://github.com/flutter/flutter/issues/143845
## Tests
Adds two tests.
`DevFSBytesContent` (and it's descendant `DevFSStringContent`) have setters that change the underlying content. These are unused outside of tests, so this PR removes them. Amongst other things, this could help me refactor https://github.com/flutter/flutter/pull/144660 into something that has fewer pitfalls.
This is purely a refactoring.
We should always target the newest, and 34 is the newest. This isn't a requirement yet (like it is for 33+) but presumably it will be made required in the nearish future.
I was doing some debugging on a RenderSliver subclass, and found
that SliverConstraints.toString was missing the precedingScrollExtent
field.
Add that, and add both that field and userScrollDirection to the
`==` and hashCode implementations, which had been skipping them,
so that all three methods now handle all the class's fields.
Partial implementation of https://github.com/flutter/flutter/issues/143348
This enables asset transformation during hot reload (except for web, because that has its own implementation of `DevFS` ð). Asset transformers will be reapplied after changing any asset and performing a hot reload during `flutter run`.
Explicitly handle the case where the iOS device is not paired. On `flutter run` show an error and bail instead of trying and failing to launch on the device.
On this PR:
```
$ flutter run -d 00008110-0009588C2651401E
'iPhone' is not paired. Open Xcode and trust this computer when prompted.
$
```
Fixes https://github.com/flutter/flutter/issues/144447
Closes https://github.com/flutter/flutter/pull/144095
