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
Fixes https://github.com/flutter/flutter/issues/133089
This allows more than one ParentDataWidget to write to the ParentData of a child render object. Previously only one was allowed. There are some rules though:
1. Only one of a given type of `ParentDataWidget` can write to the `ParentData` of a given child.
a. For example, 2 `Positioned` widgets wrapping a child of a `Stack` would not be allowed, as only one of type `Positioned` can contribute data.
2. The type of `ParentData` **must** be compatible with all of the `ParentDataWidget`s that want to contribute data.
a. For example, `TwoDimensionalViewportParentData` mixes in the `KeepAliveParentDataMixin`. So the `ParentData` of a given child would be compatible with the `KeepAlive` `ParentDataWidget`, as well as another `ParentDataWidget` that writes `TwoDimensionalViewportParentData` (or a subclass of `TwoDimensionalViewportParentData` - This was the motivation for this change, where a `ParentDataWidget` is being used in `TableView` with the parent data type being a subclass of `TwoDimensionalViewportParentData`.)
During a long press, on native iOS the context menu does not show until the long press has ended. The handles are shown immediately when the long press begins. This is true for static and editable text.
For static text on Android, the context menu appears when the long press is initiated, but the handles do not appear until the long press has ended. For editable text on Android, the context menu does not appear until the long press ended, and the handles also do not appear until the end.
For both platforms in editable/static contexts the context menu does not show while doing a long press drag.
I think the behavior where the context menu is not shown until the long press ends makes the most sense even though Android varies in this depending on the context. The user is not able to react to the context menu until the long press has ended.
Other details:
On a windows touch screen device the context menu does not show up until the long press ends in editable/static text contexts. On a long press hold it selects the word on drag start as well as popping up the selection handles (static text).
In the FormField widget, if a validator is initially set (and validation fails), then subsequently the validator is set to null, the form incorrectly retains its error state. This is not expected behavior as removing the validator should clear any validation errors.
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.
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/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/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
…t trap the focus
fixes https://github.com/flutter/flutter/issues/112567
Several things I done:
1. add new enum `parentScope`
2. refactor _sortAllDescendants so that it doesn't recursively looking
into its descendant when it encounter a FocusScopeNode.
3. When the nextFocus try to focus into a FocusScopeNode, it will try to
find the first focusable FocusNode in traversal order and focus it
instead if it doesn't have a first focus.
4. Change the default in Navigator to always be `parentScope`
5. Only the root navigator will use `leaveFlutterView` if platform is
web.
Previously 2 and 3 are not needed because once a focusscope trapped the
focus, there isn't a chance where the parent focusscope have to deal
with next focus.
If we don't do 2 and 3 after the change, it will cause it to stuck in
the current scope again. Because once the focus leave the current scope,
it needs to also remove the first focus in that scope (so that it can
start fresh when focus traversal back to the scope in the future). At
this point the current scope will have the primary focus without the
first focus. The parent scope will then try to find the next focus, and
it will place the focus to the first traversal child in the current
scope again.
## Pre-launch Checklist
- [ ] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [ ] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [ ] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [ ] I signed the [CLA].
- [ ] I listed at least one issue that this PR fixes in the description
above.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [ ] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[test-exempt]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
[Discord]: https://github.com/flutter/flutter/wiki/Chat
