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.
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? :)
This PR aims to support Android's predictive back gesture when popping the entire Flutter app. Predictive route transitions between routes inside of a Flutter app will come later.
<img width="200" src="https://user-images.githubusercontent.com/389558/217918109-945febaa-9086-41cc-a476-1a189c7831d8.gif" />
### Trying it out
If you want to try this feature yourself, here are the necessary steps:
1. Run Android 33 or above.
1. Enable the feature flag for predictive back on the device under "Developer
options".
1. Create a Flutter project, or clone [my example project](https://github.com/justinmc/flutter_predictive_back_examples).
1. Set `android:enableOnBackInvokedCallback="true"` in
android/app/src/main/AndroidManifest.xml (already done in the example project).
1. Check out this branch.
1. Run the app. Perform a back gesture (swipe from the left side of the
screen).
You should see the predictive back animation like in the animation above and be able to commit or cancel it.
### go_router support
go_router works with predictive back out of the box because it uses a Navigator internally that dispatches NavigationNotifications!
~~go_router can be supported by adding a listener to the router and updating SystemNavigator.setFrameworkHandlesBack.~~
Similar to with nested Navigators, nested go_routers is supported by using a PopScope widget.
<details>
<summary>Full example of nested go_routers</summary>
```dart
// Copyright 2014 The Flutter Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
import 'package:go_router/go_router.dart';
import 'package:flutter/material.dart';
import 'package:flutter/scheduler.dart';
void main() => runApp(_MyApp());
class _MyApp extends StatelessWidget {
final GoRouter router = GoRouter(
routes: <RouteBase>[
GoRoute(
path: '/',
builder: (BuildContext context, GoRouterState state) => _HomePage(),
),
GoRoute(
path: '/nested_navigators',
builder: (BuildContext context, GoRouterState state) => _NestedGoRoutersPage(),
),
],
);
@override
Widget build(BuildContext context) {
return MaterialApp.router(
routerConfig: router,
);
}
}
class _HomePage extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: const Text('Nested Navigators Example'),
),
body: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: <Widget>[
const Text('Home Page'),
const Text('A system back gesture here will exit the app.'),
const SizedBox(height: 20.0),
ListTile(
title: const Text('Nested go_router route'),
subtitle: const Text('This route has another go_router in addition to the one used with MaterialApp above.'),
onTap: () {
context.push('/nested_navigators');
},
),
],
),
),
);
}
}
class _NestedGoRoutersPage extends StatefulWidget {
@override
State<_NestedGoRoutersPage> createState() => _NestedGoRoutersPageState();
}
class _NestedGoRoutersPageState extends State<_NestedGoRoutersPage> {
late final GoRouter _router;
final GlobalKey<NavigatorState> _nestedNavigatorKey = GlobalKey<NavigatorState>();
// If the nested navigator has routes that can be popped, then we want to
// block the root navigator from handling the pop so that the nested navigator
// can handle it instead.
bool get _popEnabled {
// canPop will throw an error if called before build. Is this the best way
// to avoid that?
return _nestedNavigatorKey.currentState == null ? true : !_router.canPop();
}
void _onRouterChanged() {
// Here the _router reports the location correctly, but canPop is still out
// of date. Hence the post frame callback.
SchedulerBinding.instance.addPostFrameCallback((Duration duration) {
setState(() {});
});
}
@override
void initState() {
super.initState();
final BuildContext rootContext = context;
_router = GoRouter(
navigatorKey: _nestedNavigatorKey,
routes: [
GoRoute(
path: '/',
builder: (BuildContext context, GoRouterState state) => _LinksPage(
title: 'Nested once - home route',
backgroundColor: Colors.indigo,
onBack: () {
rootContext.pop();
},
buttons: <Widget>[
TextButton(
onPressed: () {
context.push('/two');
},
child: const Text('Go to another route in this nested Navigator'),
),
],
),
),
GoRoute(
path: '/two',
builder: (BuildContext context, GoRouterState state) => _LinksPage(
backgroundColor: Colors.indigo.withBlue(255),
title: 'Nested once - page two',
),
),
],
);
_router.addListener(_onRouterChanged);
}
@override
void dispose() {
_router.removeListener(_onRouterChanged);
super.dispose();
}
@override
Widget build(BuildContext context) {
return PopScope(
popEnabled: _popEnabled,
onPopped: (bool success) {
if (success) {
return;
}
_router.pop();
},
child: Router<Object>.withConfig(
restorationScopeId: 'router-2',
config: _router,
),
);
}
}
class _LinksPage extends StatelessWidget {
const _LinksPage ({
required this.backgroundColor,
this.buttons = const <Widget>[],
this.onBack,
required this.title,
});
final Color backgroundColor;
final List<Widget> buttons;
final VoidCallback? onBack;
final String title;
@override
Widget build(BuildContext context) {
return Scaffold(
backgroundColor: backgroundColor,
body: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: <Widget>[
Text(title),
//const Text('A system back here will go back to Nested Navigators Page One'),
...buttons,
TextButton(
onPressed: onBack ?? () {
context.pop();
},
child: const Text('Go back'),
),
],
),
),
);
}
}
```
</details>
### Resources
Fixes https://github.com/flutter/flutter/issues/109513
Depends on engine PR https://github.com/flutter/engine/pull/39208✔️
Design doc: https://docs.google.com/document/d/1BGCWy1_LRrXEB6qeqTAKlk-U2CZlKJ5xI97g45U7azk/edit#
Migration guide: https://github.com/flutter/website/pull/8952
This change enables Flutter to generate multiple Scenes to be rendered into separate FlutterViews from a single widget tree. Each Scene is described by a separate render tree, which are all associated with the single widget tree.
This PR implements the framework-side mechanisms to describe the content to be rendered into multiple views. Separate engine-side changes are necessary to provide these views to the framework and to draw the framework-generated Scene into them.
## Summary of changes
The details of this change are described in [flutter.dev/go/multiple-views](https://flutter.dev/go/multiple-views). Below is a high-level summary organized by layers.
### Rendering layer changes
* The `RendererBinding` no longer owns a single `renderView`. In fact, it doesn't OWN any `RenderView`s at all anymore. Instead, it offers an API (`addRenderView`/`removeRenderView`) to add and remove `RenderView`s that then will be MANAGED by the binding. The `RenderView` itself is now owned by a higher-level abstraction (e.g. the `RawView` Element of the widgets layer, see below), who is also in charge of adding it to the binding. When added, the binding will interact with the `RenderView` to produce a frame (e.g. by calling `compositeFrame` on it) and to perform hit tests for incoming pointer events. Multiple `RenderView`s can be added to the binding (typically one per `FlutterView`) to produce multiple Scenes.
* Instead of owning a single `pipelineOwner`, the `RendererBinding` now owns the root of the `PipelineOwner` tree (exposed as `rootPipelineOwner` on the binding). Each `PipelineOwner` in that tree (except for the root) typically manages its own render tree typically rooted in one of the `RenderView`s mentioned in the previous bullet. During frame production, the binding will instruct each `PipelineOwner` of that tree to flush layout, paint, semantics etc. A higher-level abstraction (e.g. the widgets layer, see below) is in charge of adding `PipelineOwner`s to this tree.
* Backwards compatibility: The old `renderView` and `pipelineOwner` properties of the `RendererBinding` are retained, but marked as deprecated. Care has been taken to keep their original behavior for the deprecation period, i.e. if you just call `runApp`, the render tree bootstrapped by this call is rooted in the deprecated `RendererBinding.renderView` and managed by the deprecated `RendererBinding.pipelineOwner`.
### Widgets layer changes
* The `WidgetsBinding` no longer attaches the widget tree to an existing render tree. Instead, it bootstraps a stand-alone widget tree that is not backed by a render tree. For this, `RenderObjectToWidgetAdapter` has been replaced by `RootWidget`.
* Multiple render trees can be bootstrapped and attached to the widget tree with the help of the `View` widget, which internally is backed by a `RawView` widget. Configured with a `FlutterView` to render into, the `RawView` creates a new `PipelineOwner` and a new `RenderView` for the new render tree. It adds the new `RenderView` to the `RendererBinding` and its `PipelineOwner` to the pipeline owner tree.
* The `View` widget can only appear in certain well-defined locations in the widget tree since it bootstraps a new render tree and does not insert a `RenderObject` into an ancestor. However, almost all Elements expect that their children insert `RenderObject`s, otherwise they will not function properly. To produce a good error message when the `View` widget is used in an illegal location, the `debugMustInsertRenderObjectIntoSlot` method has been added to Element, where a child can ask whether a given slot must insert a RenderObject into its ancestor or not. In practice, the `View` widget can be used as a child of the `RootWidget`, inside the `view` slot of the `ViewAnchor` (see below) and inside a `ViewCollection` (see below). In those locations, the `View` widget may be wrapped in other non-RenderObjectWidgets (e.g. InheritedWidgets).
* The new `ViewAnchor` can be used to create a side-view inside a parent `View`. The `child` of the `ViewAnchor` widget renders into the parent `View` as usual, but the `view` slot can take on another `View` widget, which has access to all inherited widgets above the `ViewAnchor`. Metaphorically speaking, the view is anchored to the location of the `ViewAnchor` in the widget tree.
* The new `ViewCollection` widget allows for multiple sibling views as it takes a list of `View`s as children. It can be used in all the places that accept a `View` widget.
## Google3
As of July 5, 2023 this change passed a TAP global presubmit (TGP) in google3: tap/OCL:544707016:BASE:545809771:1688597935864:e43dd651
## Note to reviewers
This change is big (sorry). I suggest focusing the initial review on the changes inside of `packages/flutter` first. The majority of the changes describe above are implemented in (listed in suggested review order):
* `rendering/binding.dart`
* `widgets/binding.dart`
* `widgets/view.dart`
* `widgets/framework.dart`
All other changes included in the PR are basically the fallout of what's implemented in those files. Also note that a lot of the lines added in this PR are documentation and tests.
I am also very happy to walk reviewers through the code in person or via video call, if that is helpful.
I appreciate any feedback.
## Feedback to address before submitting ("TODO")
This is a second attempt to merge #107269. Currently I've fixed two of the issues:
1. Fixed horizontal scrollview by using a switch statement to consider vertical/horizontal case.
2. Fixed issue of `paintExtent` not being the right extent for painting. Rather using a `scrollExtent` for the main axis length of the decoration box and painting it offsetted by the `scrollOffset`.
3. If the sliver child has inifinite scrollExtent, then we only draw the decoration down to the bottom of the `cacheExtent`. The developer is expected to ensure that the border does not creep up above the cache area.
This PR includes a test that checks that the correct rectangle is drawn at a certain scrollOffset for both the horizontal and vertical case which should be sufficient for checking that `SliverDecoration` works properly now.
Fixes https://github.com/flutter/flutter/issues/107498.
* Revert "Revert "Add support for double tap and drag for text selection (#109573)" (#117497)"
This reverts commit 39fa0117a919bd401c4c8734c97ddb46fbc45cb7.
* Allow TapAndDragGestureRecognizer to accept pointer events from any devices -- the TapGestureRecognizer it replaces was previously doing this
Co-authored-by: Renzo Olivares <roliv@google.com>
* Replace PanGestureRecognizer in TextSelection with TapAndDragGestureRecognizer
* add tracking of _DragState to new tap_and_drag recognizer and remove some legacy double tap code from text_selection.dart and add logs"
* add dragTapCount, a tap count that is persistent for an entire drag and is set to null on drag end vs the regular tap count which is reset on a timer
* basic double tap to drag functionality and add a local dragTapCount in text_selection.dart to use with the timer callback
* Add offsetFromOrigin and localOffsetFromOrigin to DragUpdateDetails similar to LongPressMoveUpdateDetails, eliminates the need to hold the state of lastDragStartDetails
* make a generic baselongpressgesturerecognizer
* Revert "make a generic baselongpressgesturerecognizer"
This reverts commit aad8f7433bd01e4cd016d527af832c3b1f15fac5.
* rename tap_and_drag to selection_recognizers
* add mixin for consecutivetap
* tap and long press gesture recognizer
* Revert "Revert "make a generic baselongpressgesturerecognizer""
This reverts commit 181350c36718f644eada3e45c1b7b5939f90a340.
* Revert "Revert "Revert "make a generic baselongpressgesturerecognizer"""
This reverts commit 4d69775967858dfd66dd9429e1713da598908a85.
* Add support for secondary button clicks on drag gesture recognizer and separate drag end and tap up callback
* get test running
* rename tapCount to consecutiveTapCount
* dispose timer properly
* add some comments to tests
* Add comments
* Make ConsecutiveTapMixin private and move logic to increment tap count into mixin
* stop tracking pointer when gesture is rejected and detect drags on touch devices
* onCancel for TapAndDrag
* have the TapAndDragGestureRecognizer handle tap downs and tap ups on touch and mouse devices
* add drag to move cursor for android and iOS, and pointer device kind to DragUpdateDetails
* get tests running
* refactor TapAndDragGestureRecognizer moving some logic into _check methods
* Handle cancel properly on TapAndDragGestureRecognizer, having both onTapCancel and onDragCancel, also fix tests
* Fix test mouse drag selects and cannot drag cursor, save _initialPosition based on dragStartBehavior (either on tapDown or dragStart)
* determine if drag has a sufficient global distance to accept and fix some cancel behavior, making _checkCancel clearer
* give up pointer on drag end
* properly stop tracking pointer, fixes test for right click on Apple and non-apple platforms
* clean up some comments from last commit
* remove drag on touch for now
* fix Can select text by dragging with a mouse due to dragStart only being fired on the first PointerMoveEvent, the previous pan gesture recognizer would fire both dragStart and dragUpdate
* Revert "fix Can select text by dragging with a mouse due to dragStart only being fired on the first PointerMoveEvent, the previous pan gesture recognizer would fire both dragStart and dragUpdate"
This reverts commit 124dc79bc3389672c76d7c014ce04edab297abc6.
* correctly use _initialPosition for checkStart and call _checkUpdate after _checkStart if localDelta is not zero
* updates
* fix double tap chains
* Add docs
* Address analyzer
* more analyzer, only issues left are with print statements
* add deadlineTimer to fix conflict with ForcePressGestureRecognizer
* Revert "add deadlineTimer to fix conflict with ForcePressGestureRecognizer"
This reverts commit 3b29ddfff4cde4845edd481ecefb789fea2a0781.
* remove unecessary changes to tests
* secondaryButton should not drag
* Revert "Revert "add deadlineTimer to fix conflict with ForcePressGestureRecognizer""
This reverts commit 0a008f029f5796acd48c17c1897c0b700d5ef3a7.
* updates
* Revert "updates"
This reverts commit 4803b8443a2b67f0b8d29e9a01f712dfcb0f588c.
* Revert "Revert "Revert "add deadlineTimer to fix conflict with ForcePressGestureRecognizer"""
This reverts commit 79251a7af88d5dbb1460a960afc77e65dea18bff.
* fix shift + tap + drag tests, this was happening because a double tap + drag was being registered and not a single tap, added a duration to pumpAndSettle to fix this
* remove TapAndLongPressGestureRecognizer
* fix cupertino text field tests related to shift + tap + drag
* deadline timer try 2
* more logs
* Should reset taps when tap cancel is called, and should wait until gesture is accepted to initiate a drag
* should clear _down and _up when gesture is rejected
* remove erroneous log
* fix selectable text double tap chains test
* dont restart timer until tap up
* reset consecutiveTapCount on drag end
* fix selectableText test
* fix material text field tests
* reject TapAndDragGestureRecognizer when it is neither a tap nor a drag
* remove prints
* clean up
* shift aware
* clean up
* fix cupertino test
* fix text field focus tests
* Add 100ms delay to cupertino test, to prevent a double tap
* clean up test comments
* add comment to test
* uncomment test
* remove longpress changes
* Fix drag on mobile
* remove debug
* Fix drag to move cursor on iOS
* left over from drag fix
* add tests for drag on touch devices
* add test for double tap + drag mouse devices
* add tests
* Fix bug where initialPosition was used before it was set
* Address some review comments and fix issue where if double tap was held too long then long press gesture recognizer would take over
* remove _isDoubleTap flag since it is no longer needed due to previous commit
* Add docs for onTapCancel and onDragCancel
* analyzer fixes
* Do not test selection handles on macOS, since macOS does not support touch
* Add assert for dragStartBehavior
* add double tap + drag tests to cupertino
* use kDoubleTapTimeout instead of const Duration(milliseconds: 300) for readability
* analyzer issues
* update docs
* update more docs
* address comments
* more doc updates
* fix docs
* unused import
* fix docs
* Add more tests
* Add more tests and reject a tap up if we have exceeded the tap tolerance
* updates
* Address comments
* fix test naming
* update documentation
* move selection_recognizers to selection_gestures
* fix analyzer
* fix analyzer
* keysPressedOnDown instead of isShiftPressed
* update docs
* update docs
* Add drag update throttle to TapAndDragGestureRecognizer
* update comments
* missed from merge
* Replace _ConsecutiveTapMixin with _TapStatusTrackerMixin
* updates
* correctly cancel tap when when past tap tolerance with new implementation
* Should call tap and drag cancel if we are giving up a pointer without succesfully tracking a PointerUpEvent
* comments
* move pastTapTolerance to tap tracker
* move pastTapTolerance to tap tracker
* clean up check for nulls and remove use of consecutiveTapCountWhileDragging
* move call to super.acceptGesture to top
* remove print
* clean up
* Fix tests where both PanGestureRecognizer and TapAndDragGestureRecognizer lost
* clean up
* _GestureState -> _DragState
* more docs clean up
* more clean up
* Add onSecondaryTapCancel
* Add docs
* more docs
* Fix broken isPointerAllowed when attempting a right click drag - the _initialButtons is never reset
* revert debug flag
* make primaryPointer private
* Add support for upper count limit in TapAndDragGestureRecognizer, the tap counter should not be allowed to grow infinitely unless that is desired
* fix analyzer
* Use new TapDrag details objects and callbacks
* clean up docs
* clean up and add test for upperLimit
* Add docs for TapAndDragGestureRecognizer and remove some ambiguity of onStart onUpdate and onEnd parameters
* Address review comments
* analyzer fixes
* Call cancel before rejecting the gesture so we can still access _initialButtons
* Recognizer should reject any pointer differing from the original
* Revert "Recognizer should reject any pointer differing from the original"
This reverts commit afd9807480bd11e119bdd2b7d520631511973bab.
* Address reviewer comments
* Correct cancel behavior
* Fix consecutive tap + drag because _dragStart state was not being set when consecutive tap is greater than one
* Add more tests
* Add documentation on behavior with TapGestureRecognizer and DragGestureRecognizer
* more docs
* more docs
* remove comments
* updates
* fix multiple pointer behavior
* only handle the primary pointer
* Clean up dangerous assumptions in gesture details objects
* forgot from rebase
* update docs
* updates
* Clean up some redundant code
* remove whitespace
* fix tests as a result of #115849
* update test docs
* Fix same test from last commit for material variants
* More clean up of redundant code and update docs
* Clean up didStopTrackingLastPointer and untie TapAndDragGestureRecognizer cancel behavior from TapStatusTrackerMixin.currentUp state
* untie pastTapTolerance
* updates
* Add slopTolerance
* update docs
* Have secondary tap handled by TapGestureRecognizer
* update docs
* fix analyzer and address comments
* Add more docs
* Update cancel behavior tol not call on tap cancel when a drag has been accepted
* Change cancel behavior to only cancel if the tap down callback has been sent and merge tapcancel and dragcancel
* update docs;
* Rename selection_gestures to tap_and_drag_gestures
* Address some reviewer comments
* make deadline and slopTolerance private
* updates
* updates
* Address review comments
* remove _initialButtons
* fix docs
* trackTrap -> trackTap
* fix analyzer
* Add test to verify that tap up is called when recognizer accepts before handleEvent is called
* implement Diagnosticable for Details objects;
* sentTapDown == wonArenaForPrimaryPointer, so the implementation now only uses sentTapDown
* Count user tap up immediately and do not wait to win the arena
* Do not need to call super from TapAndDragGestureRecognizer.acceptGesture anymore because mixin implementation is gone
* Do not start selection drag on Android, iOS, and Fuchshsia touch devices if renderEditable does not have focus, this fixes many scubas
* Address reviewer comments
* fix test
* TapAndDragGestureRecognizer should wait for other recognizer to lose before winning the arena
* Address review comments
* Dont check for drag if the start was already found
* Only check for a drag if it has not already been found"
* fix from rebase
Co-authored-by: Renzo Olivares <roliv@google.com>
* Reland "Inject current `FlutterView` into tree and make available via `View.of(context)` (#116924)"
This reverts commit 9102f2fe0bd26db6074ac4a17785296cd341ecb9.
* remove window placeholder
* Can show context menus anywhere in the app, not just on text.
* Unifies all desktop/mobile context menus to go through one class (ContextMenuController).
* All context menus are now just plain widgets that can be fully customized.
* Existing default context menus can be customized and reused.
Implements a PlatformMenuBar widget and associated data structures for defining menu bars that use native APIs for rendering.
This PR includes:
A PlatformMenuBar class, which is a widget that menu bar data can be attached to for sending to the platform.
A PlatformMenuDelegate base, which is the type taken by a new WidgetsBinding.platformMenuDelegate.
An implementation of the above in DefaultPlatformMenuDelegate that talks to the built-in "flutter/menu" channel to talk to the built-in platform implementation. The delegate is so that a plugin could override with its own delegate and provide other platforms with native menu support using the same widgets to define the menus.
This is the framework part of the implementation. The engine part will be in flutter/engine#32080 (and flutter/engine#32358)
