## 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
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.
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
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.
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
