When a `TextField` is rendered before a `Navigator`, it breaks in semantics mode. This is because the framework generates the incorrect semantics tree (excludes the TextField) and when that tree gets sent to the engine, we don't get the signal to create the corresponding `<input>` element.
This happens for a few reasons:
* `ModalBarrier` uses `BlockSemantics` to drop the semantics of routes beneath the current route in `Navigator`
* `ModalBarrier` mistakenly recognizes the widget outside of the `Navigator` to be its sibling
* So we end up dropping the semantics node of the `TextField` rendered before it.
The fix is to let `Navigator` generate a semantics node so that `ModalBarrier` doesn't mistakenly think widgets outside of `Navigator` are its siblings.
`Navigator` doesn't currently do this, which causes all the nodes generated from its widget subtree to be directly attached to the parent semantics node above `Navigator` - since this is also the parent of `TextField`, it considers them siblings.
Fixes https://github.com/flutter/flutter/issues/129324
This PR adds the Dart VM `vm:platform-const-if` pragma introduced in
https://github.com/dart-lang/sdk/commit/57a1168875 to the
`defaultTargetPlatform` property, allowing it to be computed as if it
was a constant field in non-debug AOT builds. In particular, this means
that platform-specific code executed conditionally based on this
property can be tree-shaken in release builds. Note that this PR changes
`defaultTargetPlatform` to only allow overriding via
`debugDefaultTargetPlatformOverride` in debug builds, and makes it so
that compilation throws an error if code assigns
to`debugDefaultTargetPlatformOverride` in other build modes.
Related issue: #14233
## Pre-launch Checklist
- [X] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [X] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [X] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [X] I signed the [CLA].
- [X] I listed at least one issue that this PR fixes in the description
above.
- [X] I updated/added relevant documentation (doc comments with `///`).
- [X] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [X] All existing and new tests are passing.
Remove more `textScaleFactor` references from flutter/flutter.
- Some changes are related to label scaling: the padding EdgeInsets values of some chip subclasses scale linearly between predetermined "max" padding values and "min" padding values. Before they scale with the `textScaleFactor` scalar, now they scale with the font size and are still capped at the original "max" and "min" values.
- The rest of them are tests or size heuristics that depend on `textScaleFactor`, these are replaced by an effective text scale factor computed using a default font size (which is determined in a pretty random fashion, but it will only make a difference on Android 14+).
No API changes in this batch. There are still some references left that I intend to remove in a different batch that would introduce API changes.
This PR improves the distance between the label and the icon in the Tab widget.
I updated the margin to 2 pixels, taken from the Figma design page for Material 3. On Material 2 I left the default value of 10 pixels.
Related to #128696 (In particular, the distance between label and icon)
Here are some screenshots for comparison. I looked a bit into the other mentioned issue of the tab height not following the M3 spec. Flutter uses 72 and the spec uses 64. But because Tab is a PreferredSizeWidget, I don't think there is an easy way to provide a different size depending on `ThemeData.useMaterial3`, because there is no `BuildContext` available.
I provide a sample image for the 64 height as well for context on the linked issue, even though it's not part of the PR changes.
The screenshots are taken side by side with the image at: https://m3.material.io/components/tabs/guidelines
## Original
## New (tab height = 72, Flutter default for 8 years)
## New (tab height = 64, M3 spec)
Previously `TextField`s error `cursorColor` was being derived without taking into account any `InputDecorationTheme` defaults. This change respects `InputDecorationTheme` defaults when deriving the error `cursorColor`.
Fixes#140607
Fixes#140046
This PR is to add a `headerHeight` property to `SearchAnchor` and `SearchViewThemeData` so the header height on the search view can be customized.
I continued [my mission](https://github.com/flutter/flutter/pull/141431) to find as many typos as I could. This time it's a smaller set than before.
There is no need for issues since it's a typo fix.
## Description
This PR addresses issue #141061, which requested the addition of a 'color' property to buttons extending _ActionButton. The 'color' property has been introduced to enhance customization options for these buttons.
## Issues Fixed
- Fixes#141061
Reverts flutter/flutter#141526
Initiated by: CaseyHillers
This change reverts the following previous change:
Original Description:
### Description
- Adds `BoxPainter` creation and disposal events dispatching for memory leak tracking as part of https://github.com/flutter/flutter/issues/141198
### Tests
- Updates `decoration_test.dart` to test `BoxPainter` object creation and disposal events dispatching.
Fixes #140770 and #103124
Adds the possibility of passing a height and width to icons. And also a margin for the distance of the lines between the icons.
fixes [Invisible SliverAppBar title in Material 3 light theme](https://github.com/flutter/flutter/issues/138296)
fixes [`FlexibleSpaceBar` title is misaligned without the leading widget](https://github.com/flutter/flutter/issues/138608)
Previous attempt https://github.com/flutter/flutter/pull/138611
---
### Description
- fixes the `FlexibleSpaceBar` centered title position when there is a leading widget.
- fixes the `FlexibleSpaceBar` title color for Material 3.
- Added documentation when using a long `FlexibleSpaceBar` title and update its test.
- Improved documentation of default title padding.
### Code sample
### Code sample
<details>
<summary>expand to view the code sample</summary>
```dart
import 'package:flutter/material.dart';
void main() => runApp(const MyApp());
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return const MaterialApp(
debugShowCheckedModeBanner: false,
home: Example(),
);
}
}
class Example extends StatelessWidget {
const Example({super.key});
@override
Widget build(BuildContext context) {
return const Scaffold(
body: SafeArea(
child: CustomScrollView(
slivers: <Widget>[
SliverAppBar(
leading: Icon(Icons.favorite_rounded),
flexibleSpace: FlexibleSpaceBar(
title: ColoredBox(
color: Color(0xffff0000),
child: Text('SliverAppBar'),
),
),
),
],
)),
);
}
}
```
</details>
### Before
### After
While working in https://pub.dev/packages/two_dimensional_scrollables, I found I could eliminate some casts if we added covariants here in the framework.
Much of the 2D aPI in the framework is abstract, so I think it make sense to add these and make it easier/cleaner for subclasses using the APIs.
I made a similar change in https://github.com/flutter/flutter/pull/131358, this would cover all of the cases I could find so its nice and accommodating now.
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.
(#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.
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>
