Fixes https://github.com/flutter/flutter/issues/131467
An error in the flex methods of min and max column width would produce different results based on the position of the widths that were provided:
`MaxColumnWidth(a, b) != MaxColumnWidth(b, a)`
This fixes that.
I get confused when reading this comment. It seems that this code never calls `AnimationController.fling` (but only things like `animateTo`). Therefore, I do not think discussing the duration of `AnimationController.fling` is helpful - maybe it is just an outdated comment?
## Description
This PR is a reland of https://github.com/flutter/flutter/pull/129274 with a fix and new test related to the revert (https://github.com/flutter/flutter/pull/131303).
It updates how a floating snack bar is positionned when a `Scaffold` defines a FAB with `Scaffold.floatingActionButtonLocation` sets to one of the top locations.
**Before this PR:**
- When a FAB location is set to the top of the `Scaffold`, a floating `SnackBar` can't be displayed and an assert throws in debug mode.
**After this PR:**
- When a FAB location is set to the top of the `Scaffold`, a floating `SnackBar` will be displayed at the bottom of the screen, above a `NavigationBar` for instance (the top FAB is ignored when computing the floating snack bar position).
## Motivation
This is a edge case related to a discrepancy between the Material spec and the Flutter `Scaffold` customizability:
- Material spec states that a floating `SnackBar` should be displayed above a FAB. But, in Material spec, FABs are expected to be on the bottom.
- Since https://github.com/flutter/flutter/issues/51465, Flutter `Scaffold` makes it valid to show a FAB on the top of the `Scaffold`.
## Related Issue
fixes https://github.com/flutter/flutter/issues/128150
## Tests
Adds 2 tests.
Pragma will allow future proofing Dart snapshot utilities to work by preserving the names of important classes used in platform channel communication
@Hixie
These tweaks came from https://github.com/flutter/packages/pull/4536
- The TwoDimensionalChildBuilderDelegate asserts that maxXIndex and maxYIndex are null or >= 0
- The TwoDimensionalChildDelegate setter in RenderTwoDimensionalViewport has a covariant to allow type safety for subclasses of RenderTwoDimensionalViewport implementing with other subclasses of TwoDimensionalChildDelegate
I'd like to cherry pick this so https://github.com/flutter/packages/pull/4536 will not have to wait for it to reach stable.
Updated golden tests in
* ink_sparkle_test.dart
* material_test.dart
* page_test.dart
* progress_indicator_test.dart
to have M2 and M3 versions.
More info in #127064
This primarily implements DecorationImage.lerp().
It also makes some minor tweaks, the main one of which is defering to dart:ui for `clampDouble` instead of duplicating it in package:foundation.
Fixes https://github.com/flutter/flutter/issues/12452
Reverts flutter/flutter#129274
temporarily putting up a revert in case a fix is difficult
context: [b/293202068](http://b/293202068) youtube integration tests failed
The Apple Human Interface Guidelines give a specific ordering of the symbols
used as modifier keys in menu shortcuts. These guidelines are encoded into
the native Cocoa or UIKit menu classes, and are intended to ensure that symbols
are always aligned into columns of like symbols and do not move around in the
case of dynamic menu items (for example, holding Option will transform certain
menu items into different versions that take the Option key, so the Option key
symbol appears to the left of most other symbols to avoid reordering).
The Material spec says to use symbols for modifier keys on Mac and iOS, as this
is what users there are familiar with. It stands to reason that we should
follow the platform guidelines fully, so this changes the MenuItemButton class
to honor the HIG-compliant symbol ordering on Mac and iOS.
Fixed: #129308
Android may choose to letterbox applications that lock orientation. This gets particularly bad on foldable devices, where a developer may want to lock orientation when the devices is folded and unlock when unfolded. However, if the app is letterboxed when unfolded, the `MediaQuery.of(context).size` will never report the full display size, only the letterboxed window size. This may result in an application getting "stuck" in portrait mode.
/cc @TytaniumDev
This PR updates `BottomAppBar` and `BottomAppBarTheme` tests for M3 migration.
More info in https://github.com/flutter/flutter/issues/127064
- Some tests are M2 or M3 only.
- Added several M3 tests.
- One golden change.
Adding the `scrollControlDisabledMaxHeightRatio` parameter for modal bottom sheet widgets, and using the default value `9.0 / 16.0` to avoid breaking.
Resolves#129690.
Reverts flutter/flutter#130484. /cc @ronnnnn
Example failure: https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20framework_tests_libraries/12185/overview
<details>
<summary>Failure logs...</summary>
```
04:51 +5379 ~18: /Volumes/Work/s/w/ir/x/w/flutter/packages/flutter/test/material/about_test.dart: Barrier dismissible Barrier is dismissible with default parameter
âââ¡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK âââââââââââââââââââââââââââââââââââââââââââââââââââââ
The following TestFailure was thrown running a test:
Expected: <1>
Actual: <2>
When the exception was thrown, this was the stack:
#4 main.<anonymous closure>.<anonymous closure> (file:///Volumes/Work/s/w/ir/x/w/flutter/packages/flutter/test/material/about_test.dart:776:7)
<asynchronous suspension>
#5 testWidgets.<anonymous closure>.<anonymous closure> (package:flutter_test/src/widget_tester.dart:165:15)
<asynchronous suspension>
#6 TestWidgetsFlutterBinding._runTestBody (package:flutter_test/src/binding.dart:1008:5)
<asynchronous suspension>
<asynchronous suspension>
(elided one frame from package:stack_trace)
This was caught by the test expectation on the following line:
file:///Volumes/Work/s/w/ir/x/w/flutter/packages/flutter/test/material/about_test.dart line 776
The test description was:
Barrier is dismissible with default parameter
ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
04:51 +5379 ~18 -1: /Volumes/Work/s/w/ir/x/w/flutter/packages/flutter/test/material/about_test.dart: Barrier dismissible Barrier is dismissible with default parameter [E]
Test failed. See exception logs above.
The test description was: Barrier is dismissible with default parameter
To run this test again: /Volumes/Work/s/w/ir/x/w/flutter/bin/cache/dart-sdk/bin/dart test /Volumes/Work/s/w/ir/x/w/flutter/packages/flutter/test/material/about_test.dart -p vm --plain-name 'Barrier dismissible Barrier is dismissible with default parameter'
```
</details>
### Overview
Add `barrierDismissible`, `barrierColor` and `barrierLabel` parameters to `showDatePicker`, `showTimePicker` and `showAboutDialog` which calls `showDialog` internally.
We can change these parameters with `showDialog` and Dialog widgets (like `DatePickerDialog`, `TimePickerDialog` or `AboutDialog`) directly. But, I think it is prefer to provide interfaces same as `showDialog` to keep application wide unified looks if it is used internally.
Fixes#130971
## Description
This PR updates how a floating snack bar is positionned when a `Scaffold` defines a FAB with `Scaffold.floatingActionButtonLocation` sets to one of the top locations.
**Before this PR:**
- When a FAB location is set to the top of the `Scaffold`, a floating `SnackBar` can't be displayed and an assert throws in debug mode.
**After this PR:**
- When a FAB location is set to the top of the `Scaffold`, a floating `SnackBar` will be displayed at the bottom of the screen, above a `NavigationBar` for instance (the top FAB is ignored when computing the floating snack bar position).
## Motivation
This is a edge case related to a discrepancy between the Material spec and the Flutter `Scaffold` customizability:
- Material spec states that a floating `SnackBar` should be displayed above a FAB. But, in Material spec, FABs are expected to be on the bottom.
- Since https://github.com/flutter/flutter/issues/51465, Flutter `Scaffold` makes it valid to show a FAB on the top of the `Scaffold`.
## Related Issue
fixes https://github.com/flutter/flutter/issues/128150
## Tests
Adds 1 test.
This PR changes the material date picker behavior when changing the year so that it matches the native picker and the material component guideline. (#81547)
See material component guideline for the date picker: [Material component date-picker behavior](https://m3.material.io/components/date-pickers/guidelines#1531a81f-4052-4a75-a20d-228c7e110156)
See also: [Material components android discussion](https://github.com/material-components/material-components-android/issues/1723)
When selecting another year in the native picker, the same day will be selected (by respecting the boundaries of the date picker). The current material date picker does not select any day when changing the year. This will lead to confusion if the user presses OK and the year does not get updated.
So here is my suggestion:
It will try to preselect the day like the native picker:
- respecting the boundaries of the date picker (firstDate, lastDate)
- changing from leapyear 29th february will set 28th february if not a leapyear is selected
- only set the day if it is selectable (selectableDayPredicate)
The calendar shown in the recording was setup with this parameters:
```
firstDate: DateTime(2016, DateTime.june, 9),
initialDate: DateTime(2018, DateTime.may, 4),
lastDate: DateTime(2021, DateTime.january, 15),
```
https://github.com/flutter/flutter/assets/13588771/3041c296-b9d0-4078-88cd-d1135fc343b3Fixes#81547
The change in [0] has propagated now everywhere, so we can use
`utf8.encode()` instead of the longer `const Utf8Encoder.convert()`.
Also it cleans up code like
```
TypedData bytes;
bytes.buffer.asByteData();
```
as that is not guaranteed to be correct, the correct version would be
```
TypedData bytes;
bytes.buffer.asByteData(bytes.offsetInBytes, bytes.lengthInBytes);
```
a shorter hand for that is:
```
TypedData bytes;
ByteData.sublistView(bytes);
```
[0] https://github.com/dart-lang/sdk/issues/52801
