This change makes `_SelectableRegionContainerDelegate` public so it can be reused and extended by users of `SelectionContainer`. Extending `MultiSelectableRegionContainerDelegate` does not by default provide selection managing across multiple selectables, so often users will copy the implementation found in `_SelectableRegionContainerDelegate`.
`_SelectableRegionContainerDelegate` -> `StaticSelectionContainerDelegate`.
This PR fixes the `shouldCloseOnMinExtent` flag in `draggable_scrollable_sheet.dart`.
*The `shouldCloseOnMinExtent` flag was not functioning correctly in the `DraggableScrollableSheet` widget. This PR ensures that the flag is properly handled, preventing the sheet from closing when it reaches the minimum extent if the flag is set to false. Before/after screenshots are not applicable for this change.*
In the code sample below, before my fix, the sheet would close when scrolled down. After my fix, it behaves as expected by respecting the `shouldCloseOnMinExtent` parameter.
### Code Sample
```dart
import 'package:flutter/material.dart';
Future<void> main() async {
runApp(const MaterialApp(
home: Home(),
));
}
class Home extends StatelessWidget {
const Home({
super.key,
});
@override
Widget build(BuildContext context) => Scaffold(
body: Center(
child: FilledButton(
onPressed: () async => showModalBottomSheet(
context: context,
isScrollControlled: true,
isDismissible: false,
builder: (context) => DraggableScrollableSheet(
expand: false,
maxChildSize: 0.9,
minChildSize: 0.25,
initialChildSize: 0.5,
shouldCloseOnMinExtent: false,
builder: (context, scrollController) => Navigator(
onGenerateRoute: (settings) => MaterialPageRoute(
settings: settings,
builder: (context) => ListView.builder(
controller: scrollController,
itemExtent: 100,
itemCount: 100,
itemBuilder: (context, index) => Center(
child: Text('$index'),
),
),
),
),
),
),
child: const Text('Open sheet'),
),
),
);
}
```
Inspired by the review on #146182.
This PR adds boundary feature to the drag gestures, including `MultiDragGestureRecognizer` and `DragGestureRecognizer`. The `GestureDetector` widget will also benefit from this.
## Description
Relands https://github.com/flutter/flutter/pull/156968 wich was reverted in https://github.com/flutter/flutter/pull/157378
This PR makes `EditableText` aware of the lifecycle 'resumed' state to let the current selection unchanged when the application is resumed (on web and desktop, 'resumed' means the Flutter app window regained focus).
Before this PR, on web and desktop, the whole content of a `TextField` was selected whenever a `TextField` gained focus. This is the correct behavior when tabbing between fields but it is not when a field regains focus after the application is resumed
## Related Issue
Fixes [When switching to another browser tab or window and then going back, all text on TextField is selected automatically](https://github.com/flutter/flutter/issues/156078).
## Tests
Adds 1 test.
Reverts: flutter/flutter#156968
Initiated by: jacobsimionato
Reason for reverting: Google3 roll failing - see b/375019489
Original PR Author: bleroux
Reviewed By: {justinmc, gspencergoog}
This change reverts the following previous change:
## Description
This PR makes `EditableText` aware of the lifecycle 'resumed' state to let the current selection unchanged when the application is resumed (on web and desktop, 'resumed' means the Flutter app window regained focus).
Before this PR, on web and desktop, the whole content of a `TextField` was selected whenever a `TextField` gained focus. This is the correct behavior when tabbing between fields but it is not when a field regains focus after the application is resumed
## Related Issue
Fixes [When switching to another browser tab or window and then going back, all text on TextField is selected automatically](https://github.com/flutter/flutter/issues/156078).
## Tests
Adds 1 test.
Hit testing behavior is currently hardcoded to `opaque` in `HtmlElementView` which causes the platform view to swallow pointer events when it's a descendant of a `GestureDetector` (see this [example](https://dartpad.dev/?id=5348fbf82be5eeb7d995f953437f0ce6)).
In order to fix this, we need to make `hitTestBehavior` configurable in `HtmlElementView`. This way users can decide to make their platform views `transparent` for hit testing purposes.
**_Note_**: this specific case isn't fixable by `PointerInterceptor` because the framework is already receiving the pointer events, so there's nothing that `PointerInterceptor` can do. This issue is all happening on the framework side since it treats the rectangle occupied by the platform view as an opaque rectangle for hit testing.
**_Workaround_**: in the meantime, users can work around this limitation by surrounding the `HtmlElementView` with an `IgnorePointer` widget.
## Description
This PR makes `EditableText` aware of the lifecycle 'resumed' state to let the current selection unchanged when the application is resumed (on web and desktop, 'resumed' means the Flutter app window regained focus).
Before this PR, on web and desktop, the whole content of a `TextField` was selected whenever a `TextField` gained focus. This is the correct behavior when tabbing between fields but it is not when a field regains focus after the application is resumed
## Related Issue
Fixes to [When switching to another browser tab or window and then going back, all text on TextField is selected automatically](https://github.com/flutter/flutter/issues/156078).
## Tests
To be done
Adds `onTapUpOutside` and `onTapUpInside` callbacks to `TapRegion`, and `onTapUpOutside` to `EditableText` text fields. This allows users to detect `PointerUpEvent`s, which in turn can be used to differentiate between a tap and pan / scroll gesture (for example by comparing the distance between the down and up events).
Fixes#140271 and potentially #138190
This class looks like it _should_ give valid equality checks:
```dart
class _WidgetStateColorMapper extends _WidgetStateColorTransparent {
const _WidgetStateColorMapper(this.map);
final WidgetStateMap<Color> map;
_WidgetStateMapper<Color> get _mapper => _WidgetStateMapper<Color>(map);
@override
Color resolve(Set<WidgetState> states) => _mapper.resolve(states);
@override
bool operator ==(Object other) {
return other is _WidgetStateColorMapper && other.map == map;
}
@override
int get hashCode => map.hashCode;
}
```
But I made a mistake: I should have used `other._mapper == _mapper` and `_mapper.hashCode`.
<br>
It'd be pretty nice if no copy-pasting was needed in the first place:
```dart
class _WidgetStateColorMapper extends WidgetStateMapper<Color> implements WidgetStateColor {
const _WidgetStateColorMapper(super.map);
}
```
<br><br>
This PR makes `WidgetStateMapper` a public class, similar to `WidgetStatePropertyAll`. The new API, when used incorrectly, will `throw` with a detailed error message, rather than silently returning irrelevant values.
This PR adds `TapOutsideConfiguration` where you can define a custom default logic for `onTapOutside`.
```dart
TapOutsideConfiguration(
behavior: AlwaysUnfocusTapOutsideBehavior(),
// behavior: const NeverUnfocusTapOutsideBehavior(),
// behavior: const CustomTapOutsideBehavior(),
child: Column(
children: [
// This TextField will use onTapOutside from TapOutsideConfiguration
TextField(),
// Of course you can still define onTapOutside
TextField(onTapOutside: (event) => print('Tapped outside')),
],
),
)
```
Custom logic can be define like this:
```dart
class CustomTapOutsideBehavior extends TapOutsideBehavior {
const CustomTapOutsideBehavior();
@override
void defaultOnTapOutside(PointerDownEvent event, FocusNode focusNode) {
// any custom logic here
}
}
```
This PR implements also two simple `AlwaysUnfocusTapOutsideBehavior` and `NeverUnfocusTapOutsideBehavior`.
Resolves#150123
NavigatorPopHandler now includes the return value from Route. Recently some navigation infrastructure was updated to support passing through these return values, but NavigatorPopHandler was missed until now.
This pull request aims to improve code readability, based on feedback gathered in a recent design doc.
<br>
There are two factors that hugely impact how easy it is to understand a piece of code: **verbosity** and **complexity**.
Reducing **verbosity** is important, because boilerplate makes a project more difficult to navigate. It also has a tendency to make one's eyes gloss over, and subtle typos/bugs become more likely to slip through.
Reducing **complexity** makes the code more accessible to more people. This is especially important for open-source projects like Flutter, where the code is read by those who make contributions, as well as others who read through source code as they debug their own projects.
<hr>
<br>
The following examples show how pattern-matching might affect these two factors:
<details> <summary><h3>Example 1 (GOOD)</h3> [click to expand]</summary>
```dart
if (ancestor case InheritedElement(:final InheritedTheme widget)) {
themes.add(widget);
}
```
Without using patterns, this might expand to
```dart
if (ancestor is InheritedElement) {
final InheritedWidget widget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(widget);
}
}
```
Had `ancestor` been a non-local variable, it would need to be "converted" as well:
```dart
final Element ancestor = this.ancestor;
if (ancestor is InheritedElement) {
final InheritedWidget inheritedWidget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(theme);
}
}
```
</details>
<details> <summary><h3>Example 2 (BAD) </h3> [click to expand]</summary>
```dart
if (widget case PreferredSizeWidget(preferredSize: Size(:final double height))) {
return height;
}
```
Assuming `widget` is a non-local variable, this would expand to:
```dart
final Widget widget = this.widget;
if (widget is PreferredSizeWidget) {
return widget.preferredSize.height;
}
```
<br>
</details>
In both of the examples above, an `if-case` statement simultaneously verifies that an object meets the specified criteria and performs a variable assignment accordingly.
But there are some differences: Example 2 uses a more deeply-nested pattern than Example 1 but makes fewer useful checks.
**Example 1:**
- checks that `ancestor` is an `InheritedElement`
- checks that the inherited element's `widget` is an `InheritedTheme`
**Example 2:**
- checks that `widget` is a `PreferredSizeWidget`
(every `PreferredSizeWidget` has a `size` field, and every `Size` has a `height` field)
<br>
<hr>
I feel hesitant to try presenting a set of cut-and-dry rules as to which scenarios should/shouldn't use pattern-matching, since there are an abundance of different types of patterns, and an abundance of different places where they might be used.
But hopefully the conversations we've had recently will help us converge toward a common intuition of how pattern-matching can best be utilized for improved readability.
<br><br>
- resolves https://github.com/flutter/flutter/issues/152313
- Design Doc: [flutter.dev/go/dart-patterns](https://flutter.dev/go/dart-patterns)
Fixes#33799
Allows for a route to inform the route below it in the navigation stack how to animate when the topmost route enters are leaves the stack.
It does this by making a `DelegatedTransition` available for the previous route to look up and use. If available, the route lower in the stack will wrap it's transition builders with that delegated transition and use it instead of it's default secondary transition.
This is what the sample code in this PR shows an app that is able to use both a Material zoom transition and a Cupertino slide transition in one app. It also includes a custom vertical transition. Every page animates off the screen in a way to match up with the incoming page's transition. When popped, the correct transitions play in reverse.
https://github.com/user-attachments/assets/1fc910fa-8cde-4e05-898e-daad8ff4a697
The below video shows this logic making a pseudo iOS styled sheet transition.
https://github.com/flutter/flutter/assets/58190796/207163d8-d87f-48b1-aad9-7e770d1d96c5
All existing page transitions in Flutter will be overwritten by the incoming route if a `delegatedTransition` is provided. This can be opted out of through `canTransitionTo` for a new route widget. Of Flutter's existing page transitions, this PR only adds a `DelegatedTransition` for the Zoom and Cupertino transitions. The other transitions possible in Material will get delegated transitions in a later PR.
This PR fixes the `ReorderableList` in `flutter/widgets.dart` not passing the item extent builder to the underlying SliverReorderableList. I double checked and the material equivalent is working as intended.
Fixes https://github.com/flutter/flutter/issues/155936
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Fixes https://github.com/flutter/flutter/issues/155551
### Description
- Adds example for `WidgetStateMouseCursor`
- Adds tests for `examples/api/lib/widgets/widget_state/widget_state_mouse_cursor.0.dart`
This PR tweaks `wrapWithDefaultView` (used by `runApp`) to raise a StateError with a legible error message when the `platformDispatcher.implicitView` is missing (for example, when enabling multi-view embedding on the web), instead of crashing with an unexpected `nullCheck` a few lines below.
* Before:
<img width="619" alt="Screenshot 2024-09-25 at 7 33 47â¯PM" src="https://github.com/user-attachments/assets/4897dd3c-bdd0-4217-9f23-7eee9fab4999">
* After:
<img width="613" alt="Screenshot 2024-09-26 at 5 01 49â¯PM" src="https://github.com/user-attachments/assets/3febb91d-a8c3-41b6-bf34-c2c8743b637c">
## Issues
* Fixes https://github.com/flutter/flutter/issues/153198
## Tests
Added a test to ensure the assertion is thrown when the `implicitView` is missing. Had to hack a little because I couldn't find any clean way of overriding the `implicitView`. The problem is that the flutter_test bindings [use `runApp` internally](8925e1ffdf/packages/flutter_test/lib/src/binding.dart (L1020)) a couple of times, so I can only disable the implicitView inside the test body (and must re-enable it before returning). Not sure if it's the best way, but it seems to do the trick for this simple test case!
Fixes https://github.com/flutter/flutter/issues/155557
### Description
- Adds example for `WidgetStateBorderSide`
- Adds tests for `examples/api/lib/widgets/widget_state/widget_state_border_side.0.dart`
fixes#154515, #150048 and other similar issues where user non-draggable scrolls (mouse wheel, two-fingers) should behave same as draggable ones.
In this PR, scrollUpdateNotification.dragDetails check is removed and it has a supporting test which simulates a scroll which does not produce a drag.
This PR contributes to https://github.com/flutter/flutter/issues/155313
### Description
- Adds example for `WidgetStateProperty`
- Adds tests for `examples/api/lib/widgets/widget_state/widget_state_property.0.dart`
Fix: Flicker when no update in index of dragged item
Resolves#150843
This PR ensures that even if we move dragged item anywhere in list and comeback to initial position, we smoothly adjust to that position.
## Description
This PR fixes the default selection on desktop when a text field is gaining focus.
Before this PR, when a text field is focused, the selection was collapsed at the end for all platforms except on Web where the entire content was selected.
After this PR, when a text field is focused, the entire content is selected on desktop and Web, and the selection is collapsed at the end on mobile platforms.
The implementation extends the work done in https://github.com/flutter/flutter/pull/119583 which implemented this feature for web.
## Related Issue
Fixes https://github.com/flutter/flutter/issues/150339.
## Tests
Updates 1 test.
Fixes 2 tests.
Fixes https://github.com/flutter/flutter/issues/154060
The error message doesn't make sense to me since one can call `setState` during the idle phase, and I'm not sure what this is guarding against without the right error message.
In the case of #154060 the layout builder was never laid out:
```
ââchild 1: _RenderLayoutBuilder#7c319 NEEDS-LAYOUT NEEDS-PAINT
â creator: LayoutBuilder â _BodyBuilder â MediaQuery â
â LayoutId-[<_ScaffoldSlot.body>] â CustomMultiChildLayout â
â _ActionsScope â Actions â AnimatedBuilder â DefaultTextStyle â
â AnimatedDefaultTextStyle â _InkFeatures-[GlobalKey#1f6eb ink
â renderer] â NotificationListener<LayoutChangedNotification> â â¯
â parentData: offset=Offset(0.0, 0.0); id=_ScaffoldSlot.body
â constraints: MISSING
â size: MISSING
```
So https://github.com/flutter/flutter/pull/154681 doesn't really fix#154060 since the layout callback cannot be run without a set of valid constraints.
Before the `BuildScope` change all `_inDirtyList` flags were unset after the `BuildOwner` finishes rebuilding the widget tree, so `LayoutBuilder._inDirtyLst` is always set to false after a frame even for layout builders that were never laid out.
With the `BuildScope` change, `LayoutBuilder` has its own `BuildScope` which is only flushed after LayoutBuilder gets its constraints.
Fixes https://github.com/flutter/flutter/issues/154156
Some iOS keyboard implementations change the selection in the text field if dismissed with active composing regions. The framework should not call `requestKeyboard` in such cases since that would bring up the keyboard again.
In general the `TextInput.show` call is not needed for selection only changes. For working around https://github.com/flutter/flutter/issues/68571 the show call is needed only if we restarted the input on Android (and we don't restart on selection-only changes any way).
Fixes#153889 an issue where nodes were being removed incorrectly when using `AnimationStyle.noAnimation `or the animation duration was zero seconds, which previously caused the application to freeze due to hidden state updates. By skipping the animation and updating active nodes immediately in these cases, we avoid these issues and ensure smooth and accurate management of node states.
SearchBar and SearchAnchor can now control their context menu. They both received new contextMenuBuilder parameters. See the docs for EditableText.contextMenuBuilder for how to use this, including how to use the native context menu on iOS and to control the browser's context menu on web.
This PR is _almost_ able to close issue #89127.
Sadly, no `InheritedModel` or custom `RenderObject`s today; instead the [WidgetState operators](https://main-api.flutter.dev/flutter/widgets/WidgetStateOperators.html) have been restructured to support equality checks.
`WidgetStateProperty.fromMap()` is now capable of accurate equality checks, and all of the `.styleFrom()` methods have been refactored to use that constructor.
(Equality checks are still broken for `WidgetStateProperty.resolveWith()`, and any other non-`const` objects that implement the interface.)
<br><br>
credit for this idea goes to @justinmc: https://github.com/flutter/flutter/issues/89127#issuecomment-2313187703
