This PR fixes scrolling issues with `NestedScrollView` using the `BouncingScrollPhysics`. In one of the steps of the calculation, we can reach a state where the position of the inner scrollable is set to a `double` value that falls within `precisionErrorTolerance` of `0` but we were using `==` with `0` rather than checking for a precision. My posts in the linked issue show the current behavior, and how I reached to conclusion (the code in this PR). This PR only addresses the "jumping" of the outer scrollable.
Fixes#136199
I have not finished a test for this since I have never done so and therefore have 0 experience writing tests in Flutter, so any help there would be appreciated. I am also not sure how to test double precision errors in general. I did run all the nested_scroll_view_tests.dart locally and there are no failures.
Fixes#141140.
This ensures that if you call `.copyWith` and pass a `debugLabel`, the `debugLabel` won't be ignored, even if the receiver (the TextStyle you're calling `.copyWith` on) doesn't have a `debugLabel`.
The debugLabel field was added in #12552. I skimmed the discussion there and didn't find anything indicating that the param was being ignored on purpose.
I added a test case that passes with the new code and fails with the old code.
Replace `as Map<Object?, Object?>` to handle nullable case
Fixes runtime issue in Wasm
*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 reverts commit
d24c01bd0c.
The original change was reverted because it caused some apps to get
stuck on the splash screen on some phones.
An investigation determined that this was due to a rounding error.
Example: The device reports a physical size of 1008.0 x 2198.0 with a
dpr of 1.912500023841858. Flutter would translate that to a logical size
of 527.0588169589221 x 1149.2810314243163 and use that as the input for
its layout algorithm. Since the constraints here are tight, the layout
algorithm would determine that the resulting logical size of the root
render object must be 527.0588169589221 x 1149.2810314243163.
Translating this back to physical pixels by applying the dpr resulted in
a physical size of 1007.9999999999999 x 2198.0 for the frame. Android
now rejected that frame because it didn't match the expected size of
1008.0 x 2198.0 and since no frame had been rendered would never take
down the splash screen.
Prior to dynamically sized views, this wasn't an issue because we would
hard-code the frame size to whatever the requested size was.
Changes in this PR over the original PR:
* The issue has been fixed now by constraining the calculated physical
size to the input physical constraints which makes sure that we always
end up with a size that is acceptable to the operating system.
* The `ViewConfiguration` was refactored to use the slightly more
convenient `BoxConstraints` over the `ViewConstraints` to represent
constraints. Both essentially represent the same thing, but
`BoxConstraints` are more powerful and we avoid a couple of translations
between the two by translating the` ViewConstraints` from the
`FlutterView` to `BoxConstraints` directly when the `ViewConfiguration`
is created.
All changes over the original PR are contained in the second commit of
this PR.
Fixes b/316813075
Part of https://github.com/flutter/flutter/issues/134501.
Introduced `validateGranually` which, apart from announcing the errors to the UI, returns a `Map<Key, bool>` providing more granular validation details: The results of calling `validate` on each `FormField` and their corresponding widget keys.
* related issue: #135363
fixes [`RouteObserver` example throws an error](https://github.com/flutter/flutter/issues/141078)
### Description
This updates the `RouteObserver` example from snippet to Dartpad example and fixes the error when running the code snippet
## Description
This PR adds custom system-wide text selection toolbar buttons on Android for `SelectableRegion` and `SelectionArea`.
https://github.com/flutter/flutter/pull/139738 adds those buttons for `EditableText` (which is used by `TextField` and `SelectableText` but not by `SelectionArea`).
## Related Issue
Step 5 for https://github.com/flutter/flutter/issues/139361
## Tests
Adds 2 tests.
## Description
This PR fixes an issue related to the spell check implementation usage of Regex (searched text should be escaped).
## Related Issue
Fixes https://github.com/flutter/flutter/issues/136032.
## Tests
Adds 1 test.
Support for FFI calls with @Native external functions through Native assets on Android add to app. 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 Android add2app
The `.so` files are bundled with the same mechanism that bundles `libapp.so`.
(#139572) I would like to request an update to the document to resolve confusion.
I actually modified the code by applying priority as in the comment in [#139572](https://github.com/flutter/flutter/issues/139572) as shown below, but I thought that if 'OutlinedBorder' was used for 'shape', the default value of side for 'OutlinedBorder' was also the developer's intention.
```
OutlinedBorder _getShape(ThemeData theme, ChipThemeData chipTheme, ChipThemeData chipDefaults) {
final BorderSide? resolvedSide =
MaterialStateProperty.resolveAs<BorderSide?>(widget.side, materialStates)
?? MaterialStateProperty.resolveAs<BorderSide?>(chipTheme.side, materialStates);
final BorderSide? resolvedShapeSide =
MaterialStateProperty.resolveAs<BorderSide?>(widget.shape?.side, materialStates)
?? MaterialStateProperty.resolveAs<BorderSide?>(chipTheme.shape?.side, materialStates);
final OutlinedBorder resolvedShape =
MaterialStateProperty.resolveAs<OutlinedBorder?>(widget.shape, materialStates)
?? MaterialStateProperty.resolveAs<OutlinedBorder?>( chipTheme.shape, materialStates)
?? MaterialStateProperty.resolveAs<OutlinedBorder?>(chipDefaults.shape, materialStates)
// TODO(tahatesser): Remove this fallback when Material 2 is deprecated.
?? const StadiumBorder();
// If the side is provided, shape uses the provided side.
if (resolvedSide != null) {
return resolvedShape.copyWith(side: resolvedSide);
}
if (resolvedShapeSide != null) {
return resolvedShape.copyWith(side: resolvedShapeSide);
}
// If the side is not provided
// then the shape's side is used. Otherwise, the default side is used.
return resolvedShape.copyWith(side: chipDefaults.side);
}
```
(in `chip.dart`)
However, (#133856) PR seems to be intended to ignore this and use the aspect of `chipDefault.side` even if the developer specifies `shape.side` as [Border.none] without explicitly applying `side` .
This is probably because the default value of OutlinedBorder is [Border.none].
I think this is an area that can cause enough confusion, but there are a lot of things that need to be modified to reduce confusion through code changes, and the impact on existing code is likely to be significant.
I also confirmed that this is not accurately explained in the API Docs.
So rather than modifying the code, I decided to add additional explanation to the `shape` comment.
If the results are different from what you intended or the updated content is strange, please review. ð
Changes drag release logic so that an armed refresh is only canceled if the user has scrolled back up beyond the point where the refresh indicator was armed. (Fixes https://github.com/flutter/flutter/issues/138848.)
This is the minimal change I found could be made to restore something like the behavior that I would expect.
This may still need a bit of work, because it only masks the second issue I mentioned, that releasing a drag can cause the scroll position to be animated back up from the release point. There is actually a bug about that: https://github.com/flutter/flutter/issues/6052. I would like to see that bug fixed too. This PR doesn't address that, but makes it harder to hit that issue.
@Piinks this is a recreation of #139015 (since I couldn't figure out some issue with a git detached branch, so I fixed the PR and I'm re-submitting it). This version includes one line that was somehow accidentally dropped from the original PR. This will hopefully fix the test failures.
However, I don't have a clue how to write a test for a Flutter UI widget. I'll try to figure that out, but also I don't have a lot of time to work on this. I would appreciate at least some user testing to verify that the new behavior is much more intuitive than the old behavior.
- [?] All existing and new tests are passing.
Fix and unskip the following CanvasKit tests:
- `test/painting/decoration_test.dart`
- `test/rendering/layers_test.dart`
- `test/widgets/app_overrides_test.dart`
[Fix] Consistency in ButtonStyleButton related Tests:
- Replaced the usage of ElevatedButton with FilledButton in FilledButton's test.
- Replaced the usage of TextButton.styleFrom with FilledButton.styleFrom in FilledButton's test.
- Replaced the usage of TextButton.styleFrom with ElevatedButton.styleFrom in ElevatedButton's test.
Currently podhelper.rb will always point plugin builds at the cached engine artifacts, even when using `--local-engine`. In most cases this is fine, since when the final build actually runs it will be using the engine bundled into the app build, which will be the correct local engine build. When trying to test a local engine build with API additions against a local plugin modified to use those additions to ensure that they are working as expected, however, compilation will fail, because the new APIs won't be present in the plugin build.
This fixes that for macOS, and adds a TODO for iOS (which is more complicated to fix due to the host vs target build distinction).
macOS portion of https://github.com/flutter/flutter/issues/132228
Change the following in the `flutter create` templates. I didn't make any auto-migrations for existing apps because none seem that critical:
1. Turn on `ASSETCATALOG_COMPILER_GENERATE_SWIFT_ASSET_SYMBOL_EXTENSIONS` in iOS and macOS.
1. Turn on `BuildIndependentTargetsInParallel` in macOS template. https://github.com/flutter/flutter/pull/125827/files#r1181817619
1. Turn on `DEAD_CODE_STRIPPING` in macOS template.
1. Set `ENABLE_USER_SCRIPT_SANDBOXING=NO` in iOS and macOS template. `flutter` scripts don't work with this on. This might require a migration in the future to explicitly turn this one off. However at least for now if the setting isn't present it defaults to `NO`.
Add migration for `LastUpgradeVersion` so users won't see these validation issues in Xcode.
Run migrator on all the example apps. A few aren't Flutter apps so I edited them in Xcode.
Fixes https://github.com/flutter/flutter/issues/140253
See also https://github.com/flutter/flutter/issues/125817 and https://github.com/flutter/flutter/pull/90304.
fixes https://github.com/flutter/flutter/issues/138289
---
SegmentedButtom.styleFrom has been added to the segment button, so there is no longer any need to the button style from the beginning. It works like ElevatedButton.styleFrom only I added selectedForegroundColor, selectedBackgroundColor. In this way, the user will be able to change the color first without checking the MaterialState states. I added tests of the same controls.
#129215 I opened this problem myself, but I was rejected because I handled too many items in a PR. For now, I wrote a structure that only handles MaterialStates instead of users.
old (still avaliable)
<img width="626" alt="image" src="https://github.com/flutter/flutter/assets/65075121/9446b13b-c355-4d20-bda2-c47a23d42d4f">
new (just an option for developer)
<img width="483" alt="image" src="https://github.com/flutter/flutter/assets/65075121/0a645257-4c83-4029-9484-bd746c02265f">
### Code sample
<details>
<summary>expand to view the code sample</summary>
```dart
import 'package:flutter/material.dart';
/// Flutter code sample for [SegmentedButton].
void main() {
runApp(const SegmentedButtonApp());
}
enum Calendar { day, week, month, year }
class SegmentedButtonApp extends StatefulWidget {
const SegmentedButtonApp({super.key});
@override
State<SegmentedButtonApp> createState() => _SegmentedButtonAppState();
}
class _SegmentedButtonAppState extends State<SegmentedButtonApp> {
Calendar calendarView = Calendar.day;
@override
Widget build(BuildContext context) {
return MaterialApp(
theme: ThemeData(useMaterial3: true),
home: Scaffold(
body: Center(
child: SegmentedButton<Calendar>(
style: SegmentedButton.styleFrom(
foregroundColor: Colors.amber,
visualDensity: VisualDensity.comfortable,
),
// style: const ButtonStyle(
// foregroundColor: MaterialStatePropertyAll<Color>(Colors.deepPurple),
// visualDensity: VisualDensity.comfortable,
// ),
segments: const <ButtonSegment<Calendar>>[
ButtonSegment<Calendar>(
value: Calendar.day,
label: Text('Day'),
icon: Icon(Icons.calendar_view_day)),
ButtonSegment<Calendar>(
value: Calendar.week,
label: Text('Week'),
icon: Icon(Icons.calendar_view_week)),
ButtonSegment<Calendar>(
value: Calendar.month,
label: Text('Month'),
icon: Icon(Icons.calendar_view_month)),
ButtonSegment<Calendar>(
value: Calendar.year,
label: Text('Year'),
icon: Icon(Icons.calendar_today)),
],
selected: <Calendar>{calendarView},
onSelectionChanged: (Set<Calendar> newSelection) {
setState(() {
calendarView = newSelection.first;
});
},
),
),
),
);
}
}
```
</details>
Fixes https://github.com/flutter/flutter/issues/140665 by replacing use of `setUpAll` and `teardownAll` with `setUp` and `teardown` respectively.
My theory has to how this issue happened (and how this PR fixes it) is that `setUpAll` is not guaranteed to run after any `setUp` in any parent test groups. However, `setUp` is guaranteed to run after any set-up callbacks in parent groups. From the [documentation](https://api.flutter.dev/flutter/flutter_test/setUp.html):
> If this is called within a test group, it applies only to tests in that group. The body will be run after any set-up callbacks in parent groups or at the top level.
Meanwhile, [`setUpAll`](https://api.flutter.dev/flutter/flutter_test/setUpAll.html) has a weaker documented guarantee that applies only to other `setUpAll` calls:
> If this is called within a test group, The body will run before all tests in that group. It will be run after any [setUpAll](https://api.flutter.dev/flutter/flutter_test/setUpAll.html) callbacks in parent groups or at the top level. It won't be run if none of the tests in the group are run.
