## Description
This PR fixes form fields in order to call the `onChange` callback when the form is reset.
This change is based on the work done in https://github.com/flutter/flutter/pull/123108.
I considered adding the `onChange` callback to the `FormField` superclass but it would break existing code because two of the three subclasses defines the `onChange` callback with `ValueChanged<String>?` type and the third one defines it with `ValueChanged<String?>?`.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/123009.
## Tests
Adds 3 tests.
When it comes to startup profiling, it is very helpful to look at platform channels. `debugProfilePlatformChannels` today only works in debug and profile mode. Unfortunately, using profile mode is less accurate for startup profiling, because of the service isolate introducing additional overhead.
This PR allows this toggle to work in release mode. Note that there are two parts to `debugProfilePlatformChannels`:
- Adding timeline events
- Logging statistics about platform channels
I also considered adding a separate toggle to limit the scope of this change to the former, but that seems like complexity that we might not need at this time.
Towards #102189
## Description
This removes all of the comments that are of the form "so-and-so (must not be null|can ?not be null|must be non-null)" from the cases where those values are defines as non-nullable values.
This PR removes them from the widgets library.
This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some.
In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow.
This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases. I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these).
## Related PRs
- https://github.com/flutter/flutter/pull/134984
- https://github.com/flutter/flutter/pull/134991
- https://github.com/flutter/flutter/pull/134993
- https://github.com/flutter/flutter/pull/134994
## Tests
- Documentation only change.
## Description
This removes all of the comments that are of the form "so-and-so (must not be null|can ?not be null|must be non-null)" from the cases where those values are defines as non-nullable values.
This PR removes them from the animation, cupertino, foundation, gestures, semantics, and services libraries. Each of them only had a few, so I lumped them together.
This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some.
In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow.
This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases. I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these).
## Related PRs
- https://github.com/flutter/flutter/pull/134991
- https://github.com/flutter/flutter/pull/134992
- https://github.com/flutter/flutter/pull/134993
- https://github.com/flutter/flutter/pull/134994
## Tests
- Documentation only change.
## Description
This removes all of the comments that are of the form "so-and-so (must not be null|can ?not be null|must be non-null)" from the cases where those values are defines as non-nullable values.
This PR removes them from the material library.
This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some.
In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow.
This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases. I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these).
## Related PRs
- https://github.com/flutter/flutter/pull/134984
- https://github.com/flutter/flutter/pull/134992
- https://github.com/flutter/flutter/pull/134993
- https://github.com/flutter/flutter/pull/134994
## Tests
- Documentation only change.
## Description
This removes all of the comments that are of the form "so-and-so (must not be null|can ?not be null|must be non-null)" from the cases where those values are defines as non-nullable values.
This PR removes them from the painting and rendering libraries.
This was done by hand, since it really didn't lend itself to scripting, so it needs to be more than just spot-checked, I think. I was careful to leave any comment that referred to parameters that were nullable, but I may have missed some.
In addition to being no longer relevant after null safety has been made the default, these comments were largely fragile, in that it was easy for them to get out of date, and not be accurate anymore anyhow.
This did create a number of constructor comments which basically say "Creates a [Foo].", but I don't really know how to avoid that in a large scale change, since there's not much you can really say in a lot of cases. I think we might consider some leniency for constructors to the "Comment must be meaningful" style guidance (which we de facto have already, since there are a bunch of these).
## Related PRs
- https://github.com/flutter/flutter/pull/134984
- https://github.com/flutter/flutter/pull/134991
- https://github.com/flutter/flutter/pull/134992
- https://github.com/flutter/flutter/pull/134994
## Tests
- Documentation only change.
This PR modifies the web build slightly to create an `AssetManifest.json`, that is a JSON(base64)-encoded version of the `AssetManifest.bin` file.
_(This should enable all browsers to download the file without any interference, and all servers to serve it with the correct headers.)_
It also modifies Flutter's `AssetManifest` class so it loads and uses said file `if (kIsWeb)`.
### Issues
* Fixes https://github.com/flutter/flutter/issues/124883
### Tests
* Unit tests added.
* Some tests that run on the Web needed to be informed of the new filename, but their behavior didn't have to change (binary contents are the same across all platforms).
* I've deployed a test app, so users affected by the BIN issue may take a look at the PR in action:
* https://dit-tests.web.app
Reverts flutter/flutter#125927
context: b/300804374
Looks like a g3 fix might involve changing the names of widget on the customer app, and I am not sure if that would be the right approach forward. Putting up a revert to be safe for now.
## Description
This PR fixes `NavigationRail` hover position when text direction is set to RTL and `NavigationRail.extended` is true.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/134361.
## Tests
Adds 1 test.
## Description
This PR fixes `NavigationRail` hover position when using enlarged icons whose size is specified using `NavigationRailThemeData.selectedIconTheme` and `NavigationRailThemeData.unselectedIconTheme`.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/133799.
## Tests
Adds 1 test, updates 1 test (to replace some magic numbers).
Fix issue where if you drag the last element of `ReorderableList` and put it in the same index, a `Null check` error arises. This happens as index in `_items` is out of bounds (when `reverse: true`). Fix is to check if last element, dragged element and drop index is same, and return as nothing has changed. Find this video attached.
https://github.com/flutter/flutter/assets/84124091/8043cac3-eb08-42e1-87e7-8095ecab09dc
Fixes issue #132077
Fixes https://github.com/flutter/flutter/issues/133325
Due to the number of uniforms present, the ink_sparkle shader can't run without post processing (on all target platforms) that the impellerc offline compiler doesn't perform. However, we can't just move the uniforms into a uniform buffer object (UBO) because the Skia backend doesn't support it.
Rather than work around this in the compiler, we can reduce the uniform count by 1) packing four floats into a single vec4 2) removing a uniform for what is effectively a constant.
This should have no visible effects, and if any scubas fail it means I did this wrong ð
Fixes https://github.com/flutter/flutter/issues/133545
` child._layoutSurrogate.markNeedsLayout();` was called when `_skipMarkNeedsLayout` is set true so when there's no relayout boundary between the layout surrogate and the RenderTheater, no dirty render objects will be added to the PipelineOwner's dirty list.
It's ok to mark the RenderTheater dirty when there's no layout boundary between it and the layout surrogate.
Fixes https://github.com/flutter/flutter/issues/134142
The description for the SliverList.list example was just wrong, describing something other than the sample. ð
Tweaked some of the language on the others while I was here.
Fixes https://github.com/flutter/flutter/issues/113431
Currently we only support specifying all slivers to have the same extent.
This patch introduces an `itemExtentBuilder` property for `ListView`, allowing the slivers to have different extents while still having scrolling performance, especially when the scroll position changes drastically(such as scrolling by the scrollbar or controller.jumpTo()).
@Piinks Hi, Any thoughts about this? :)
`AnimationController` and `CurvedAnimation` objects were not disposed in `RenderAnimatedSize`.
### Description
- Fixes https://github.com/flutter/flutter/issues/133903;
- Adds the missing `dispose()` calls for `AnimationController` and `CurvedAnimation` in `RenderAnimatedSize`.
### Tests
- Updates `animated_size_test.dart` to test that `AnimationController` and `CurvedAnimation` are disposed after `RenderSize` disposal.
This change makes sure to call `onSelectionChange` in all cases when selection might change including:
* Dragging selection handles
* Mouse drag to select
* Keyboard actions
* Long press drag to select
