### Description
- Fixes https://github.com/flutter/flutter/issues/134205.
### Tests
- Removes ignoring the `_RestorableRouteInformation` leak from `cupertino/app_test.dart`;
- Removes ignoring the `_RestorableRouteInformation` leak from `material/app_test.dart`;
- Removes ignoring the `_RestorableRouteInformation` leak from `widgets/app_test.dart`;
- Removes ignoring the `_RestorableRouteInformation` leak from `widgets/route_notification_messages_test.dart`;
- Removes ignoring the `_RestorableRouteInformation` leak from `widgets/router_restoration_test.dart`;
- Updates `widgets/router_test.dart` to use `testWidgetsWithLeakTracking`.
Some render box subclasses have a specific layout contract that is tightly coupled with other render box subclasses (e.g. two private classes in a local project file). In these cases, it is also possible that they use a constraints object that is a subclass of `BoxConstraints`. To allow for this, this change makes the `constraints` argument to `RenderBox.computeDryLayout()` a covariant argument.
For completeness' sake, this updates the other render objects in the rendering package to also use the covariant keyword for this argument.
## Description
In order for `MenuAnchor` menus to be able to not pass on the taps that close their menus, `TapRegion` needed a way to consume them. This change adds a flag to the `TapRegion`, `consumeOutsideTap` that will consume taps that occur outside of the region if the flag is set (it is false by default). The same flag is added to `MenuAnchor` to allow selecting the behavior for menus.
`TapRegion` consumes the tap event by registering with the gesture arena and immediately resolving the tap as accepted if any regions in a group have `consumeOutsideTap` set to true.
This PR also deprecates `MenuAnchor.anchorTapClosesMenu`, since it is a much more limited version of the same feature that only applied to the anchor itself, and even then only applied to closing the menu, not passing along the tap. The same functionality can now be implemented by handling a tap on the anchor widget and checking to see if the menu is open before closing it.
## Related Issues
- https://github.com/flutter/flutter/issues/135327
## Tests
- Added tests for `TapRegion` to make sure taps are consumed properly.
This PR is adding a listener to the `SearchController`, so that the `suggestionBuilder` can be updated when the `SearchController` changes.
Another method we can possibly do is have an update method on `SearchController`, so that the user can manually update the suggestions instead of us doing it automatically.
Fixes#132161
This fixes/notates a few deprecations from an audit for the next tech debt cycle.
- ThemeData errorColor and backgroundColor are notated as deprecated in multiple places, but one usage had a different version tag. Updated to match the rest.
- ThemeData.copyWith useMaterial3 was deprecated because it did not do what developers expected - it did not automatically reassign all of the color values and such. (confirmed with @HansMuller) I added a note so that when we later remove it we don't introduce a bug.
- the describeEnum deprecation was tagged wrong, it was a very long PR so by the time it merged the version it was finally tagged with was much later. (https://github.com/flutter/flutter/pull/125016)
fixes [`flexible_space_bar.dart': Failed assertion: line 475 pos 12: 'needsCompositing': is not true.` is thrown when scrolling down in the list and then up](https://github.com/flutter/flutter/issues/135698)
## Description
This adds a mechanism for listening to key events before or after focus traversal occurs.
It adds four methods to the public `FocusManager` API:
- `addEarlyKeyEventHandler` - Adds a handler that can handle events before they are given to the focus tree for handling.
- `removeEarlyKeyEventHandler` - Removes an early event handler.
- `addLateKeyEventHandler` - Adds a handler that can handle events if they have not been handled by anything in the focus tree.
- `removeLateKeyEventHandler` - Removes a late event handler.
This allows an app to get notified for a key anywhere, and prevent the focus tree from seeing that event if it handles it.
For the menu system, this allows it to eat an escape key press and close all the open menus.
## Related Issues
- https://github.com/flutter/flutter/issues/135334
## Tests
- Added tests for new functionality.
In the past I switched the implementation of the zoom page transition because the performance of the old transition was terrible, but I'm hopeful that with Impeller we'll be able to identify and fix the issues that made it so slow. In order to evaluate this though, we need to be able to opt into the old transition for benchmarks on CI.
https://github.com/flutter/flutter/issues/129742https://github.com/flutter/flutter/issues/121325
We delegate page up / page down actions to the browser. However, we don't let the browser scroll the underlying `<textarea>` - the framework handles scrolling, so page up/down don't end up doing anything. Since the framework handles scrolling for text inputs and textareas, we should let it also handle the actions for `page up`, `page down`, `home`, `end`, and their modifiers.
fixes https://github.com/flutter/flutter/issues/121867
## Description
This updates the documentation for `MediaQuery` and `Overlay` to include the following:
- That `MediaQueryData.size` is set asynchronously, and doesn't necessarily reflect the size of the current frame.
- That the specific `MediaQuery.sizeOf` and related methods are preferred over the more generic `MediaQuery.of`.
- That the size of the `Overlay` isn't necessarily the size returned by `MediaQueryData.size`
As well as adding some symbol links, and fixing some error in documentation.
## Tests
- Documentation only
This PR updates unit tests from bottom sheet tests for M3 migration.
More info in https://github.com/flutter/flutter/issues/127064
It also contains in bottom_sheet.dart where a default value took precedence over a theme attribute.
Fixes https://github.com/flutter/flutter/issues/134656
`_skipMarkNeesLayout` was meant to only skip `markNeedsLayout` calls. Re-painting is still needed when a child gets added/removed from the `Overlay`.
This PR mainly fixes several memory leaks in the `DateRangePickerDialog`.
### Description
- Fixes https://github.com/flutter/flutter/issues/136033 by:
1) adding a disposal of several `RestorableValue`;
2) creating a separate `_DayItem` stateful widget that creates/updates/disposes internal `MaterialStatesController`.
- Marks https://github.com/flutter/flutter/issues/136036.
### Tests
- Updates `test/material/date_picker_theme_test.dart` to use `testWidgetsWithLeakTracking`;
- Updates `test/material/date_range_picker_test.dart` to use `testWidgetsWithLeakTracking`.
## Description
This PR updates `_TabBarViewState.didUpdateWidget` in order to react to `TabBarView.viewportFraction`change.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/135557.
## Tests
Adds 1 test.
Resolves#128046.
Adds a services API that allows flutter app developers to write app code that determines `--flavor` the app was built with.
This is implemented by having the tool adding the value of `--flavor` to its list of dart environment declarations, which will be available to the app at run time. Specifically,`FLUTTER_APP_FLAVOR` is set. I chose this implementation for its simplicity. There is some precedent for this, but only for web ([example](cd2f3f5e78/packages/flutter_tools/lib/src/runner/flutter_command.dart (L1231))).
This PR fixes#134846. As discussed in the issue, the onSubmitted callback of a TextField is called when the browser switches tabs or is sent to the background if the flutter app is running in any mobile browser (desktop browsers are not affected). Furthermore there is no straight forward way to distinguish between onSubmitted being called because the user pressed the enter key and it being called because the user switched tabs. For example in a chat app this would cause a message to be sent when the user submits the text by pressing "send" on the virtual keyboard as well as when the user switches to another tab. The later action is likely not so much intended.
The next section explains what causes the bug and explains the proposed fix.
## Bug Analysis
The root cause for this behaviour is line 3494 in editable_text.dart: 0b540a87f1/packages/flutter/lib/src/widgets/editable_text.dart (L3487-L3499)
Only if the app is running on the web `_finalizeEditing` is called and this will then trigger the onSubmitted callback. If flutter is running on the web, there are only exactly 3 cases, in which the function is called. The following call trace analysis will describe why.
- `connectionClosed()` is only called by in one location, `_handleTextInputInvocation` of the TextInput service.
367203b301/packages/flutter/lib/src/services/text_input.dart (L1896C12-L1899)
- In particular it is only called if the TextInput service receives a 'TextInputClient.onConnectionClosed' message from the engine.
- The only location where the web part of the engine send this message is the `onConnectionClosed` function of the TextEditingChannel.
cbda68a720/lib/web_ui/lib/src/engine/text_editing/text_editing.dart (L2242-L2254)
- `onConnectionClosed` in turn is only called by the `sendTextConnectionClosedToFrameworkIfAny` function of `HybridTextEditing`.
cbda68a720/lib/web_ui/lib/src/engine/text_editing/text_editing.dart (L2340-L2345)
The function `sendTextConnectionClosedToFrameworkIfAny` is only called at 3 distinct locations of the web engine.
### 1. IOSTextEditingStrategy
As described in the comment `sendTextConnectionClosedToFrameworkIfAny` is called if the browser is sent to the background or the tab is changed.
cbda68a720/lib/web_ui/lib/src/engine/text_editing/text_editing.dart (L1632-L1656)
### 2. AndroidTextEditingStrategy
Same situation as for iOS. `sendTextConnectionClosedToFrameworkIfAny` is also called if `windowHasFocus` is false, which is the case if the browser is sent to background or the tab is changed.
cbda68a720/lib/web_ui/lib/src/engine/text_editing/text_editing.dart (L1773-L1785)
### 3. TextInputFinishAutofillContext
This call seems to always happen when `finishAutofillContext` is triggered by the framework.
cbda68a720/lib/web_ui/lib/src/engine/text_editing/text_editing.dart (L2075-L2083)
## Proposed Fix
The fixed proposed and implemented by this PR is to simply delete the call to`_finalizeEditing` in the `connectionClosed` function of editable_text.dart.
0b540a87f1/packages/flutter/lib/src/widgets/editable_text.dart (L3487-L3499)
The reasoning for this being:
* `_finalizeEditing` is only called in `connectionClosed` for the web engine.
* As explained by the trace analysis above, the web engine only triggers this `_finalizeEditing` call in 3 cases.
* In the 2 cases for IOSTextEditingStrategy and AndroidTextEditingStrategy the web engine triggering the call only causes the undesired behaviour reported in the issue.
* In the third case for TextInputFinishAutofillContext, I can't see a good reason why this would require calling `_finalizeEditing` as it only instructs the platform to save the current values. Other platforms also don't have anything that would trigger onSubmitted being called, so it seems safe to remove it.
* For other platforms the onConnectionClosed function was recently incorporated to only unfocus the TextField. So removing the call `_finalizeEditing` unifies the platform behaviour. See also
https://github.com/flutter/flutter/pull/123929https://github.com/flutter/engine/pull/41500
*List which issues are fixed by this PR. You must list at least one issue.*
#134846
To simplify the evaluation, here are two versions of the minimal example given in the issue, build with the current master and with this PR applied:
current master: https://tauu.github.io/flutter-onsubmit-test/build/web-master/
current master + PR applied: https://tauu.github.io/flutter-onsubmit-test/build/web/
This change collapses the selection at the clicked/tapped location on single click down for desktop platforms, and on single click/tap up for mobile platforms to match native.
This is a change from how `SelectionArea` previously worked. Before this change a single click down would clear the selection. From observing a native browser it looks like when tapping on static text the selection is not cleared but collapsed. A user can still attain the selection from static text using the `window.getSelection` API.
https://jsfiddle.net/juepasn3/11/ You can try this demo out here to observe this behavior yourself. When clicking on static text the selection will change.
This change also allows `Paragraph.selections` to return selections that are collapsed. This for testing purposes to confirm where the selection has been collapsed.
Partially fixes: #129583
This is a tiny tweak to replace some top level if clauses with guard clauses in `FutureBuilder`. I find the resultant code much more readable, but this is a matter of taste and I didn't see any info one way or another on it in the style guide so let me know if this is not to your all's preference.
