> ### Write Test, Find Bug
>
> When you fix a bug, first write a test that fails, then fix the bug and verify the test passes.
<br>
When `Theme.of(context)` is called in a `build()` method, the widget is rebuilt each frame during an `AnimatedTheme` transition.
I wanted to create a way for `RenderObject`s to be updated directly, so I wrote a test:
```dart
testWidgets('InheritedWidgets can trigger RenderObject updates', (WidgetTester tester) async {
// ...
});
```
â¦and it passed.
<br><br>
As it turns out, no change is needed at all!
This PR resolves#155852 by adding the "InheritedWidgets can trigger RenderObject updates" test, to ensure that this awesome capability doesn't break in the future.
This pull request aims to improve code readability, based on feedback gathered in a recent design doc.
<br>
There are two factors that hugely impact how easy it is to understand a piece of code: **verbosity** and **complexity**.
Reducing **verbosity** is important, because boilerplate makes a project more difficult to navigate. It also has a tendency to make one's eyes gloss over, and subtle typos/bugs become more likely to slip through.
Reducing **complexity** makes the code more accessible to more people. This is especially important for open-source projects like Flutter, where the code is read by those who make contributions, as well as others who read through source code as they debug their own projects.
<hr>
<br>
The following examples show how pattern-matching might affect these two factors:
<details> <summary><h3>Example 1 (GOOD)</h3> [click to expand]</summary>
```dart
if (ancestor case InheritedElement(:final InheritedTheme widget)) {
themes.add(widget);
}
```
Without using patterns, this might expand to
```dart
if (ancestor is InheritedElement) {
final InheritedWidget widget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(widget);
}
}
```
Had `ancestor` been a non-local variable, it would need to be "converted" as well:
```dart
final Element ancestor = this.ancestor;
if (ancestor is InheritedElement) {
final InheritedWidget inheritedWidget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(theme);
}
}
```
</details>
<details> <summary><h3>Example 2 (BAD) </h3> [click to expand]</summary>
```dart
if (widget case PreferredSizeWidget(preferredSize: Size(:final double height))) {
return height;
}
```
Assuming `widget` is a non-local variable, this would expand to:
```dart
final Widget widget = this.widget;
if (widget is PreferredSizeWidget) {
return widget.preferredSize.height;
}
```
<br>
</details>
In both of the examples above, an `if-case` statement simultaneously verifies that an object meets the specified criteria and performs a variable assignment accordingly.
But there are some differences: Example 2 uses a more deeply-nested pattern than Example 1 but makes fewer useful checks.
**Example 1:**
- checks that `ancestor` is an `InheritedElement`
- checks that the inherited element's `widget` is an `InheritedTheme`
**Example 2:**
- checks that `widget` is a `PreferredSizeWidget`
(every `PreferredSizeWidget` has a `size` field, and every `Size` has a `height` field)
<br>
<hr>
I feel hesitant to try presenting a set of cut-and-dry rules as to which scenarios should/shouldn't use pattern-matching, since there are an abundance of different types of patterns, and an abundance of different places where they might be used.
But hopefully the conversations we've had recently will help us converge toward a common intuition of how pattern-matching can best be utilized for improved readability.
<br><br>
- resolves https://github.com/flutter/flutter/issues/152313
- Design Doc: [flutter.dev/go/dart-patterns](https://flutter.dev/go/dart-patterns)
Add `autocorrect` and `enableSuggestions` to `SearchDelegate`, so that autocompletion can be disabled in search.
*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.*
* https://github.com/flutter/flutter/issues/98241
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Following https://github.com/flutter/flutter/pull/153982, this PR is to normalize `ThemeData.dialogTheme`; change the `DialogTheme dialogTheme` property to `DialogThemeData dialogTheme` in ThemeData. In `ThemeData()` and `ThemeData.copyWith()`, the dialogTheme parameter type is changed to `Object?` to accept both `DialogTheme` and `DialogThemeData` so that we won't cause immediate breaking change and make sure rolling is smooth. Once all component themes are normalized, these `Object?` types should be changed to `xxxThemeData`.
There's no way to create a dart fix because we can't add a "@deprecated" label for `DialogTheme`; `DialogTheme` is a new `InheritedWidget` subclass now.
Addresses the "theme normalization" sub project within https://github.com/flutter/flutter/issues/91772
Fixes#33799
Allows for a route to inform the route below it in the navigation stack how to animate when the topmost route enters are leaves the stack.
It does this by making a `DelegatedTransition` available for the previous route to look up and use. If available, the route lower in the stack will wrap it's transition builders with that delegated transition and use it instead of it's default secondary transition.
This is what the sample code in this PR shows an app that is able to use both a Material zoom transition and a Cupertino slide transition in one app. It also includes a custom vertical transition. Every page animates off the screen in a way to match up with the incoming page's transition. When popped, the correct transitions play in reverse.
https://github.com/user-attachments/assets/1fc910fa-8cde-4e05-898e-daad8ff4a697
The below video shows this logic making a pseudo iOS styled sheet transition.
https://github.com/flutter/flutter/assets/58190796/207163d8-d87f-48b1-aad9-7e770d1d96c5
All existing page transitions in Flutter will be overwritten by the incoming route if a `delegatedTransition` is provided. This can be opted out of through `canTransitionTo` for a new route widget. Of Flutter's existing page transitions, this PR only adds a `DelegatedTransition` for the Zoom and Cupertino transitions. The other transitions possible in Material will get delegated transitions in a later PR.
This PR fixes the `ReorderableList` in `flutter/widgets.dart` not passing the item extent builder to the underlying SliverReorderableList. I double checked and the material equivalent is working as intended.
Fixes https://github.com/flutter/flutter/issues/155936
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Reverts: flutter/flutter#154125
Initiated by: bartekpacia
Reason for reverting: broke postsubmit
Original PR Author: bartekpacia
Reviewed By: {reidbaker, gmackall}
This change reverts the following previous change:
Attempt to reland #142008 half a year later.
Benefit: this will be the first plugin in Flutter repo that uses Gradle KTS for Android buildscripts. Once it works fine, we can follow up with migration of more plugins later.
[The previous error message](https://github.com/flutter/flutter/pull/142008#issuecomment-1939558432) was:
```
e: /b/s/w/ir/cache/gradle/caches/jars-8/42139b5be0c79e133a7b5c5c5d5bf731/gradle-7.3.1.jar!/com/android/build/gradle/LibraryExtension.class: Class 'com/android/build/gradle/LibraryExtension' was compiled with an incompatible version of Kotlin. The binary version of its bytecode is unknown, expected version is 1.0.3
e: /b/s/w/ir/cache/gradle/caches/jars-8/043c0d54e2c1bb39208ec4477607cdf5/gradle-api-7.3.1.jar!/com/android/build/api/dsl/LibraryVariantDimension.class: Class 'com/android/build/api/dsl/LibraryVariantDimension' was compiled with an incompatible version of Kotlin. The binary version of its bytecode is unknown, expected version is 1.0.3
FAILURE: Build failed with an exception.
* Where:
Build file '/b/s/w/ir/x/w/flutter/packages/integration_test/android/build.gradle.kts' line: 36
* What went wrong:
com.android.build.gradle.LibraryExtension.setNamespace(Ljava/lang/String;)V
```
The `integration_test` plugin now puts `com.android.tools.build:gradle:8.1.0` on its classpath since https://github.com/flutter/flutter/issues/153795.
This makes me take an optimistic bet that it won't kill the autoroller now 🤞
Attempt to reland #142008 half a year later.
Benefit: this will be the first plugin in Flutter repo that uses Gradle KTS for Android buildscripts. Once it works fine, we can follow up with migration of more plugins later.
[The previous error message](https://github.com/flutter/flutter/pull/142008#issuecomment-1939558432) was:
```
e: /b/s/w/ir/cache/gradle/caches/jars-8/42139b5be0c79e133a7b5c5c5d5bf731/gradle-7.3.1.jar!/com/android/build/gradle/LibraryExtension.class: Class 'com/android/build/gradle/LibraryExtension' was compiled with an incompatible version of Kotlin. The binary version of its bytecode is unknown, expected version is 1.0.3
e: /b/s/w/ir/cache/gradle/caches/jars-8/043c0d54e2c1bb39208ec4477607cdf5/gradle-api-7.3.1.jar!/com/android/build/api/dsl/LibraryVariantDimension.class: Class 'com/android/build/api/dsl/LibraryVariantDimension' was compiled with an incompatible version of Kotlin. The binary version of its bytecode is unknown, expected version is 1.0.3
FAILURE: Build failed with an exception.
* Where:
Build file '/b/s/w/ir/x/w/flutter/packages/integration_test/android/build.gradle.kts' line: 36
* What went wrong:
com.android.build.gradle.LibraryExtension.setNamespace(Ljava/lang/String;)V
```
The `integration_test` plugin now puts `com.android.tools.build:gradle:8.1.0` on its classpath since https://github.com/flutter/flutter/issues/153795.
This makes me take an optimistic bet that it won't kill the autoroller now ð¤
## Description
This PR makes DropdownMenu rematching the initialSelection when the entries are updated.
If the new entries contains one entry whose value matches `initialSelection` this entry's label is used to initialize the inner text field, if no entries matches `initialSelection` the text field is emptied.
## Related Issue
Fixes [DropdownMenu.didUpdateWidget should re-match initialSelection when dropdownMenuEntries have changed](https://github.com/flutter/flutter/issues/155660).
## Tests
Adds 3 tests.
This PR fixes#154701 by adding a new parameter to the CarouselView widget that allows developers to control which parts of the carousel are clickable. Currently, an InkWell covers the entire carousel, preventing child widgets from being clickable even when children widget have their clickable widgets.
The new `enableSplash` parameter allows developers to disable this default behavior of `InkWell` without breaking any existing code. If `enableSplash` is `false`, the `onTap` of the `CarouselView` will be disabled. And developer can define their own click behavior likes animation, the clickable widget and so on.
Fixes https://github.com/flutter/flutter/issues/155551
### Description
- Adds example for `WidgetStateMouseCursor`
- Adds tests for `examples/api/lib/widgets/widget_state/widget_state_mouse_cursor.0.dart`
This PR addresses an issue where the `--target-platform` flag was not being respected when building APKs in debug mode. Previously, debug builds would always include `x86` and `x64` architectures, regardless of the specified target platform. This change ensures that the `--target-platform` flag is honored across all build modes, including debug.
To achieve this, `BuildApkCommand` has been slightly changed to become responsible for list of archs that should be built in the current run,rather than just parsing arguments. Previously, this responsibility was distributed to gradle, which could be frustrating (in my opinion)
Fixes#153359
Fixes#133637
This change updates the `_SelectableFragment.boundingBoxes` logic to consider the max line height. Previously we were using boxes that were tightly bound around each glyph, so you would have to click within the bounds of the glyph for double tap to select word to work. This is different than `SelectableText` which considers the max line height, as well as the native web behavior that also considers the max line height.
## Web
https://github.com/user-attachments/assets/4ce8c0ca-ec6f-4969-88b1-baa356be8278
## Flutter SelectableText
https://github.com/user-attachments/assets/54c22ad3-75d7-475b-856b-e9b2dbe09d54
## Flutter Text widget under SelectionArea
https://github.com/user-attachments/assets/27db0e2b-1d19-43cc-8ab3-16050e3a5bc7
After this change, Flutter's Text widget under a SelectionArea now matches the SelectableText and native web behavior.
This change also:
* Invalidates the cached bounding boxes when the paragraph layout changes.
* Updates `textOffsetToPosition` to consider `preferredLineHeight`. In cases when the text wraps, it was sometimes inaccurate.
Android 15 support 16k page sizes, it need [enable 16kb elf alignment](https://developer.android.com/guide/practices/page-sizes#compile-r26-lower).
the current plugin_ffi template will have below error if run on android 15 16k emulator
```
Failed to load dynamic library 'libffigen_app.so': dlopen
failed: empty/missing
DT_HASH/DT_GNU_HASH in
"/data/app/~~Ixsgxu2mj5fKxP1cXpjV6Q==/com.example.ffigen_app_example-6d_efR__WGu
4dsF4tLIaHw==/lib/arm64/libffigen_app.so"
(new hash type from the future?)
```
Add `magnificationScale `to `CupertinoMagnifier` for Zoom Effect
The CupertinoMagnifier widget is not displaying the expected zoom effect.
This issue arises because the widget internally wraps the RawMagnifier, which has its magnificationScale attribute set to the default value of 1. As a result, no magnification is applied, and the zoom effect is absent.
Fixes#155275
The "link-dry-run" functionality was never used in flutter (even before
the recent refactoring).
I think we can remove this "link-dry-run" concept everywhere.
PR to remove this in dart-lang/native:
https://github.com/dart-lang/native/pull/1613
## Description
This PR changes the `MenuAnchor` implementation in order to always show the menu on the root overlay. Doing so menus can't be hidden by other widgets especially when using go_router.
See [[go_router] DropdownMenu behind NavigationBar](https://github.com/flutter/flutter/issues/155034) where the DropdownMenu menu was displayed behind the navigation bar.
I did not make this configurable for the moment to avoid introducing a new parameter until there is a clear use case for it.
## Related Issue
Fixes [[go_router] DropdownMenu behind NavigationBar](https://github.com/flutter/flutter/issues/155034).
## Tests
Adds 1 test.
This PR tweaks `wrapWithDefaultView` (used by `runApp`) to raise a StateError with a legible error message when the `platformDispatcher.implicitView` is missing (for example, when enabling multi-view embedding on the web), instead of crashing with an unexpected `nullCheck` a few lines below.
* Before:
<img width="619" alt="Screenshot 2024-09-25 at 7 33 47â¯PM" src="https://github.com/user-attachments/assets/4897dd3c-bdd0-4217-9f23-7eee9fab4999">
* After:
<img width="613" alt="Screenshot 2024-09-26 at 5 01 49â¯PM" src="https://github.com/user-attachments/assets/3febb91d-a8c3-41b6-bf34-c2c8743b637c">
## Issues
* Fixes https://github.com/flutter/flutter/issues/153198
## Tests
Added a test to ensure the assertion is thrown when the `implicitView` is missing. Had to hack a little because I couldn't find any clean way of overriding the `implicitView`. The problem is that the flutter_test bindings [use `runApp` internally](8925e1ffdf/packages/flutter_test/lib/src/binding.dart (L1020)) a couple of times, so I can only disable the implicitView inside the test body (and must re-enable it before returning). Not sure if it's the best way, but it seems to do the trick for this simple test case!
*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].*
This change updates the behavior of `SelectableText`, to clear its selection when it loses focus and the application is currently running. This fixes the behavior where you may have multiple active highlights if you have `SelectableText` along with other "selectable" widgets such as `TextField`, or `Text` widgets under a `SelectionArea`.
If the application is in the background, for example when another window is focused, the selection should be retained so when a user returns to the application it is still there.
This change also updates the behavior of selection on macOS, single tap up, previously it was selecting the word edge closest to the tapped position, the correct behavior on native is to select the precise position. This was causing `onSelectionChanged` to be called twice, once for tap down (sets the precise tapped position, handled by logic in `TextSelectionGestureDetector`), and a second time for single tap up (moves the cursor to closest word edge, handled by logic in `_SelectableTextSelectionGestureDetectorBuilder`). This type of selection inconsistency is related to this issue https://github.com/flutter/flutter/issues/129726, I plan to look into this further in a separate PR.
Fixes#117573Fixes#103725
Changes to original CL: The code that issues an error on unsupported
operating system in the dry-run case was missing a case for iOS and
Android
Original CL description
tl;dr Removes 50% (>1650 locs) of native asset related code in
`packages/flutter_tools`
Before this PR the invocation of dart build/link/dry-run was implemented
per OS. This lead to very large code duplication of almost identical,
but slightly different code. It also led to similarly duplicated test
code.
Almost the entire dart build/link/dry-run implementation is identical
across OSes. There's small variations:
- configuration of the build (e.g. android/macos/ios version, ios sdk,
...)
- determining target locations & copying the final shared libraries
This PR unifies the implementation by reducing the code to basically two
main functions:
* `runFlutterSpecificDartBuild` which is responsible for
- obtain flutter configuration
- perform dart build (& link)
- determine target location & install binaries
* `runFlutterSpecificDartDryRunOnPlatforms` which is responsible for a
similar (but not same):
- obtain flutter configuration
- perform dart dry run
- determine target location
these two functions will call out to helpers for the OS specific
functionality:
* `_assetTargetLocationsForOS` for determining the location of the code
assets
* `_copyNativeCodeAssetsForOS` for copying the code assets (and possibly
overriting the install name, etc)
=> Since we get rid of the code duplication across OSes and have only a
single code path for the build/link/dry-run, we can also remove the
duplicated tests that were pretty much identical across OSes.
We also harden the building code by adding asserts, e.g.
* the dry fun functionality should never be used by `flutter test`
* the `build/native_assets/<os>/native_assets.yaml` should only be used
by `flutter test` and the dry-run of `flutter run`
=> We change the tests to also comply with these invariants (so the
tests are not testing things that cannot happen in reality)
We also rename `{,Flutter}NativeAssetsBuildRunner` to disambiguate it
from the `package:native_asset_builder`'s `NativeAssetsBuildRunner`.
Reverts: flutter/flutter#155430
Initiated by: eyebrowsoffire
Reason for reverting: Postsubmit failures closing the tree. See the following examples:
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios%20native_assets_ios/5738/overviewhttps://ci.chromium.org/ui/p/flutter/builders/prod/Mac_arm64_mokey%20native_assets_android/583/overviewhttps://ci.chromium.org/ui/p/flutter/builders/prod/Linux_pixel_7pro%20native_assets_android/4075/overviewhttps://ci.chromium.org/u
Original PR Author: mkustermann
Reviewed By: {bkonyi, dcharkes}
This change reverts the following previous change:
tl;dr Removes 50% (>1650 locs) of native asset related code in `packages/flutter_tools`
Before this PR the invocation of dart build/link/dry-run was implemented per OS. This lead to very large code duplication of almost identical, but sligthly different code. It also led to similarly duplicated test code.
Almost the entire dart build/link/dry-run implementation is identical across OSes. There's small variations:
- configuration of the build (e.g. android/macos/ios version, ios sdk, ...)
- determining target locations & copying the final shared libraries
This PR unifies the implementation by reducing the code to basically two main functions:
* `runFlutterSpecificDartBuild` which is responsible for
- obtain flutter configuration
- perform dart build (& link)
- determine target location & install binaries
* `runFlutterSpecificDartDryRunOnPlatforms` which is responsible for a similar (but not same):
- obtain flutter configuration
- perform dart dry run
- determine target location
these two functions will call out to helpers for the OS specific functionality:
* `_assetTargetLocationsForOS` for determining the location of the code assets
* `_copyNativeCodeAssetsForOS` for copying the code assets (and possibly overriting the install name, etc)
=> Since we get rid of the code duplication across OSes and have only a single code path for the build/link/dry-run, we can also remove the duplicated tests that were pretty much identical across OSes.
We also harden the building code by adding asserts, e.g.
* the dry fun functionality should never be used by `flutter test`
* the `build/native_assets/<os>/native_assets.yaml` should only be used by `flutter test` and the dry-run of `flutter run`
=> We change the tests to also comply with these invariants (so the tests are not testing things that cannot happen in reality)
We also rename `{,Flutter}NativeAssetsBuildRunner` to disambiguate it from the `package:native_asset_builder`'s `NativeAssetsBuildRunner`.
We also reorganize the main code to make it readable from top-down and make members private where they can be.
tl;dr Removes 50% (>1650 locs) of native asset related code in
`packages/flutter_tools`
Before this PR the invocation of dart build/link/dry-run was implemented
per OS. This lead to very large code duplication of almost identical,
but slightly different code. It also led to similarly duplicated test
code.
Almost the entire dart build/link/dry-run implementation is identical
across OSes. There's small variations:
- configuration of the build (e.g. android/macos/ios version, ios sdk, ...)
- determining target locations & copying the final shared libraries
This PR unifies the implementation by reducing the code to basically two
main functions:
* `runFlutterSpecificDartBuild` which is responsible for
- obtain flutter configuration
- perform dart build (& link)
- determine target location & install binaries
* `runFlutterSpecificDartDryRunOnPlatforms` which is responsible for a
similar (but not same):
- obtain flutter configuration
- perform dart dry run
- determine target location
these two functions will call out to helpers for the OS specific
functionality:
* `_assetTargetLocationsForOS` for determining the location of the code
assets
* `_copyNativeCodeAssetsForOS` for copying the code assets (and possibly
overriting the install name, etc)
=> Since we get rid of the code duplication across OSes and have only a
single code path for the build/link/dry-run, we can also remove the
duplicated tests that were pretty much identical across OSes.
We also harden the building code by adding asserts, e.g.
* the dry fun functionality should never be used by `flutter test`
* the `build/native_assets/<os>/native_assets.yaml` should only be used
by `flutter test` and the dry-run of `flutter run`
=> We change the tests to also comply with these invariants (so the
tests are not testing things that cannot happen in reality)
We also rename `{,Flutter}NativeAssetsBuildRunner` to disambiguate it
from the `package:native_asset_builder`'s `NativeAssetsBuildRunner`.
Reverts: flutter/flutter#155476
Initiated by: eyebrowsoffire
Reason for reverting: The newly added tests are failing in postsubmit. See https://ci.chromium.org/ui/p/flutter/builders/prod/Windows%20framework_tests_libraries/19062/overview
Original PR Author: QuncCccccc
Reviewed By: {TahaTesser}
This change reverts the following previous change:
This PR is to make preparations to make `TabBarTheme` conform to Flutter's conventions for component themes:
* Added a `TabBarThemeData` class which defines overrides for the defaults for `TabBar` properties.
* Added 2 `TabBarTheme` constructor parameters: `TabBarThemeData? data` and `Widget? child`. This is now the preferred way to configure a `TabBarTheme`:
```
TabBarTheme(
data: TabBarThemeData(labelColor: xxx, indicatorColor: xxx, ...),
child: TabBar(...)
)
```
These two properties are made nullable to not break existing apps which has customized `ThemeData.tabBarTheme`.
* Changed the type of component theme defaults from `TabBarTheme` to `TabBarThemeData`.
TODO:
* Fix internal failures.
* Change the type of `ThemeData.tabBarTheme` from `TabBarTheme` to `TabBarThemeData`. This may cause breaking changes, a migration guide will be created.
Addresses the "theme normalization" sub project within https://github.com/flutter/flutter/issues/91772
