Add support for iOS UndoManager by fbcouch · Pull Request #98294 · flutter/flutter

fbcouch · 2022-02-11T22:57:53Z

This PR is modifies the framework to allow the Undo/Redo support added by _TextEditingHistory to interact with the iOS UndoManager. That should enable 3-finger/shake gestures to undo/redo text editing and enable undo/redo from the iPad keyboard.

I don't love this approach, since it feels a little bit hacky and requires a breaking change to the TextInputClient interface. It's possible #98280 could enable a better way of doing this.

~~I haven't had a chance to test this out – still waiting for the engine to compile, but wanted to plant the flag on this and possibly feedback on the approach.~~

Related to #34749 and #77614

Engine PR: flutter/engine#31415

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.

fbcouch · 2022-02-14T03:55:53Z

I believe this is a reasonable approach – I think it may make sense to swap over to something along the lines of setUndoManagerState, though, similar to updateEditingState, where the engine can just set up the undoManager as needed, rather than having the framework manage it through three separate calls.

fbcouch · 2022-02-16T15:25:14Z

@justinmc I'd like to get your thoughts on the framework side of things – right now I'm adding a method to TextInputClient, which will make this a breaking change. I'm wondering if it would be better to add a property to the TextInputConnection for some kind of new UndoDelegate, and have the TextEditingHistory widget set itself as the current undo delegate on the connection when it receives focus. That way we could avoid that breaking change. Does that make sense?

justinmc

Just to throw out a crazy idea: What if everything in the engine through to the platform message channel were separate from text editing? Since NSUndoManager itself is not specific to text editing, hypothetically this could be generic to any kind of undo/redo. In EditableText you would specifically use it for text editing. Just a thought I had, not necessarily a good idea.

Otherwise I like the idea you mentioned of an "UndoDelegate". Kind of similar to DeltaTextInputClient?

justinmc · 2022-02-17T00:52:42Z

packages/flutter/lib/src/widgets/editable_text.dart

Why is the post frame callback needed?

justinmc · 2022-02-17T01:07:15Z

packages/flutter/lib/src/widgets/editable_text.dart

Missing docs here and on canUndo above.

justinmc · 2022-02-17T05:20:26Z

packages/flutter/lib/src/widgets/editable_text.dart

Nit: Would it be better to send a boolean from the engine? It would save a little bit of space at least.

If not, maybe parse the string into an enum or compare it to constants.

Actually, a boolean might be the best thing. I'm currently using an enum on the engine side, so I think just passing those values (0 and 1) instead of translating them to strings first might be the way to go here. Then instead of direction, this can be isRedo (or maybe split this into two methods, one to handle undo and one to handle redo)

fbcouch · 2022-02-17T15:29:39Z

Yes, I think the DeltaTextInputClient is a better version of what I was describing to avoid a breaking change...

Having everything go through a different channel is an interesting idea, for sure. Other than needing to do the weird ensureUndoEnabled trick on the engine side, everything else could be completely separate from the text editing plugin. I think that would make a lot of sense in the context of allowing programmatic control of Undo/Redo as well, so we could carve out a more generic undo/redo system where TextEditingHistory is just one implementer...I will give that some thought, for sure.

chunhtai · 2022-02-17T17:50:49Z

packages/flutter/lib/src/widgets/editable_text.dart

this can be moved out of the both if(direction == 'undo') and else case so that we don't need to duplicate code

fbcouch · 2022-02-24T18:19:40Z

Thinking about this more, I really like the idea of separating this out from the text editing details. That way a drawing app could make use of it. I haven't had a chance to work on it this week (in the middle of moving), but I'm hoping to be back at it next week.

Does it make sense to still use a FocusNode to know which undo client should receive messages or should that be something left up to the implementers? I think FocusNodes make sense for text editing, but I'm not sure about drawing. I think it still could, but maybe best left to others to decide.

My initial thought is it would make sense to have some kind of UndoActions widget (not sure on the name) that takes an UndoController or some such that provides methods like canUndo, canRedo, undo() and redo(). That's where the question about focus nodes comes in...should UndoActions take a focusNode in order to automatically manage focus, or would it make more sense to have a method on UndoController to become the receiver of undo messages?

fbcouch · 2022-03-02T22:37:47Z

I converted this back to draft status for now, since this is a work in progress.

I added a new widget, UndoHistory, and a new service, UndoManager to handle the separate communication and make this more generic.

I haven't updated EditableText to use it yet, but here's an example app that I used to mock up an Undo/Redo UI around a TextField:

lib/main.dart

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);

  // This widget is the home page of your application. It is stateful, meaning
  // that it has a State object (defined below) that contains fields that affect
  // how it looks.

  // This class is the configuration for the state. It holds the values (in this
  // case the title) provided by the parent (in this case the App widget) and
  // used by the build method of the State. Fields in a Widget subclass are
  // always marked "final".

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  final TextEditingController _controller = TextEditingController();
  final FocusNode _focusNode = FocusNode();
  final GlobalKey<UndoHistoryState> _undoKey = GlobalKey<UndoHistoryState>();

  TextStyle? get enabledStyle => Theme.of(context).textTheme.bodyMedium;
  TextStyle? get disabledStyle => Theme.of(context).textTheme.bodyMedium?.copyWith(color: Colors.grey);

  bool _canUndo = false, _canRedo = false;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        // Here we take the value from the MyHomePage object that was created by
        // the App.build method, and use it to set our appbar title.
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            UndoHistory<TextEditingValue>(
              key: _undoKey,
              value: _controller,
              onTriggered: (value) {
                _controller.value = _controller.value.copyWith(text: value.text, selection: value.selection);
              },
              focusNode: _focusNode,
              shouldChangeUndoStack: (TextEditingValue? oldValue, TextEditingValue newValue) {
                if (oldValue == null) {
                  return true;
                }

                if (newValue == TextEditingValue.empty) {
                  return false;
                }

                return oldValue.text != newValue.text;
              },
              onUndoStackChanged: () => setState(() {
                _canUndo = _undoKey.currentState?.canUndo ?? false;
                _canRedo = _undoKey.currentState?.canRedo ?? false;
              }),
              child: TextField(
                maxLines: 4,
                controller: _controller,
                focusNode: _focusNode,
              ),
            ),
            Row(
              children: [
                TextButton(
                    child: Text('Undo', style: _canUndo ? enabledStyle : disabledStyle),
                    onPressed: () {
                      _undoKey.currentState?.undo();
                    }),
                TextButton(
                    child: Text('Redo', style: _canRedo ? enabledStyle : disabledStyle),
                    onPressed: () {
                      _undoKey.currentState?.redo();
                    }),
              ],
            ),
          ],
        ),
      ),
    );
  }
}

@justinmc Let me know your thoughts on that approach. I'm also thinking it might be worth adding another level of indirection around which client is currently connected to the UndoManager, similar to TextInputConnection.

justinmc · 2022-03-07T17:54:09Z

I like that approach, looks really reusable. Would that replace _TextEditingHistory or is it separate?

fbcouch · 2022-03-07T20:42:55Z

Cool, yes, I actually was able to get to the point of replacing _TextEditingHistory on Friday: https://github.com/flutter/flutter/pull/98294/files#diff-f5f93c879cef9a102adbf148583de9f3d9a05f9678fdcad7bde106f62200bb34R3193

There are a couple of things I don't love about the implementation right now, so let me know if you have thoughts on them:

I put the API to access the undo state on UndoHistoryState, but it's not very elegant to access from a TextField(key: _key) right now: (_key.currentState as TextSelectionGestureDetectorBuilderDelegate).editableTextKey.currentState?.undoHistory?.redo(). I'm wondering if providing more direct access and/or adding another interface on to _TextFieldState might make that simpler. UndoHistoryDelegate or something like that.
To provide software undo/redo buttons, I have to manually call setState after changes, so that might be something that either the UndoHistoryDelegate could provide a stream for, or there could be a stream at another level – maybe even on the UndoManager itself.

fbcouch · 2022-03-11T19:27:27Z

All right, I swapped this over to use a controller and I think it's a lot cleaner: https://github.com/flutter/flutter/pull/98294/files#diff-0dd319c779a725fd887d8a664e656ce5cf92b62934a821cf2f3815750c630245R56

Let me know how that looks!

justinmc · 2022-03-18T20:47:09Z

CC @LongCatIsLooong who is probably also interested in this. We talked about the 3 finger swipe gesture, etc. before.

justinmc

A few quick comments here, I owe you a full review by Monday. Really excited for this PR.

justinmc · 2022-03-18T20:42:55Z

examples/api/lib/widgets/undo_history/undo_history_controller.0.dart

Nit: Period at the end.

justinmc · 2022-03-18T20:43:05Z

examples/api/lib/widgets/undo_history/undo_history_controller.0.dart

Nit: Remove this boilerplate comment.

justinmc · 2022-03-18T20:43:32Z

examples/api/lib/widgets/undo_history/undo_history_controller.0.dart

Thanks for adding a full example! Even just for me as a reviewer it helps me understand this PR.

justinmc · 2022-03-18T20:44:18Z

packages/flutter/lib/src/cupertino/text_field.dart

Nit: Maybe use a template and macro for this repeated comment.

justinmc · 2022-03-18T20:46:04Z

packages/flutter/lib/src/services/text_input.dart

Nit: Maybe add a "See also" with a reference to UndoManager.

This actually needs to be removed since the TextInput channel is no longer used by this feature

justinmc · 2022-03-18T20:49:02Z

packages/flutter/lib/src/services/undo_manager.dart

Nit: Add a "See also" with a reference to the Apple docs.

justinmc · 2022-03-18T20:52:26Z

packages/flutter/lib/src/services/undo_manager.dart

Is this separate from undo/redo gestures (3 finger swipe)?

No, that's a good point. I updated the comment to include the gestures.

justinmc · 2022-03-19T04:42:22Z

packages/flutter/lib/src/widgets/editable_text.dart

Very low chance of a breaking change here.

Is that okay? Should we leave the typedef for now, just in case?

We should remove it if it's not used by the framework.

If it passes the customer tests and the Google tests then I think it's ok to try merging it. If it does break anything, then the migration process should be pretty simple (users should include their own typedef in their app I guess?).

skia-gold · 2022-03-21T16:01:28Z

Gold has detected about 1 new digest(s) on patchset 24.
View them at https://flutter-gold.skia.org/cl/github/98294

justinmc

Mostly just small things, but one point I want to make sure everyone agrees on is the addition of the new controller (UndoHistoryController). I left a comment about that below.

Otherwise I really like this approach and the fact that undo/redo isn't tied to text editing.

Also I think the Skia Gold failure is not a problem, maybe try pushing a merge commit and see if it goes away?

justinmc · 2022-03-21T16:44:23Z

packages/flutter/lib/src/services/undo_manager.dart

Nit: Maybe handlePlatformUndo? Since it's not only a keyboard thing.

justinmc · 2022-03-21T16:47:00Z

packages/flutter/lib/src/widgets/editable_text.dart

I like this way of organizing UndoHistory 👍 . So this TextEditingValue-specific logic goes here, and UndoHistory can take a generic type parameter.

justinmc · 2022-03-21T16:48:44Z

packages/flutter/test/services/undo_manager_test.dart

Nit: Periods at the end of these comments here and below.

justinmc · 2022-03-21T16:49:22Z

packages/flutter/test/services/undo_manager_test.dart

Nit: Maybe make this private since it's not used anywhere outside of this file.

justinmc · 2022-03-21T16:51:41Z

packages/flutter/test/widgets/editable_text_utils.dart

Nit: Maybe add a comment describing this function (even though I know there wasn't one before).

Another nit here: I think that should actually be a doc comment with 3 slashes ///.

By the way, I'm glad sendKeys will be reusable now. I've wanted it in other test files before.

justinmc · 2022-03-21T17:54:32Z

packages/flutter/lib/src/widgets/undo_history.dart

I wonder what others think of this controller. It doesn't exactly follow the pattern that something like TextEditingController does because its value is UndoHistoryValue, not the actual value that is undone/redone. It kind of wraps the two ChangeNotifiers, but doesn't deal in a value itself.

Maybe that is a good thing...

Ultimately the purpose of this controller is to allow programmatic undo/redo, right? Other options:

Add this functionality to TextEditingController (though that's probably something we don't want to bloat).

List for an Intent? Undo/RedoIntent. Maybe too indirect and confusing.

This might already be the best solution as-is, but I just wanted to make sure we discuss it before committing to anything.

You are right that the UndoHistoryValue is more like a state than a value, so it is different from the TextEditingController in that way. That value is important for propagating the current undo/redo state back to the UI so that custom undo/redo interfaces can be built. The other two ChangeNotifiers are for sending events to allow programmatic undo/redo.

I don't love the idea of adding it to TextEditingController, or at least not only there, so that this can remain more generic: for example, someone could build a drawing interface with it and undo/redo lines on the drawing.

I could get on board with Intents, since we already use those for the keyboard shortcuts, though I agree that might be more confusing.

Reading through this again I think I'm onboard with UndoHistoryController as-is. It makes a lot of sense in the example you included in the examples directory.

skia-gold · 2022-03-22T15:06:29Z

Gold has detected about 1 new digest(s) on patchset 25.
View them at https://flutter-gold.skia.org/cl/github/98294

justinmc · 2022-04-29T23:19:08Z

packages/flutter/lib/src/services/undo_manager.dart

I'm currently investigating whether or not we should use a mixin in cases like this instead of an abstract class (to avoid breaking users that extend this if/when a method is added). I'll let you know what I figure out and then I owe you a full review.

Here is the design doc. There's still some debate going on.

Update: Making this a mixin and using it via with instead of implements is typically preferred. Anytime a new method is added here in the future, giving it an empty implementation will avoid breaking changes. If breaking changes are desired, a method can be added with no implementation.

justinmc

@fbcouch Are you still available to get this PR ready to merge? Sorry for the hiatus while I figured out some platform channel stuff.

justinmc · 2022-08-10T22:09:53Z

examples/api/lib/widgets/undo_history/undo_history_controller.0.dart

+                        child: Text('Undo', style: value.canUndo ? enabledStyle : disabledStyle),
+                        onPressed: () {
+                          _undoController.undo();
+                        }),


Here and below, split the closing }) onto two separate lines.

justinmc · 2022-08-10T22:11:18Z

packages/flutter/lib/src/services/undo_manager.dart

+
+/// A low-level interface to the system's undo manager.
+///
+/// To receive events from the system UndoManager, create an


Nit: "UndoManager" => "undo manager" to match the previous paragraph?

justinmc · 2022-08-10T22:17:14Z

packages/flutter/lib/src/services/undo_manager.dart

+  /// Set the [MethodChannel] used to communicate with the system's text input
+  /// control.
+  ///
+  /// This is only meant for testing within the Flutter SDK. Changing this
+  /// will break the ability to input text. This has no effect if asserts are
+  /// disabled.


This sounds like TextInputClient, can you tweak them so they're about undo/redo?

justinmc · 2022-08-10T22:26:07Z

packages/flutter/lib/src/services/undo_manager.dart

Update: Making this a mixin and using it via with instead of implements is typically preferred. Anytime a new method is added here in the future, giving it an empty implementation will avoid breaking changes. If breaking changes are desired, a method can be added with no implementation.

justinmc · 2022-08-10T22:28:42Z

packages/flutter/lib/src/services/undo_manager.dart

+  /// Will be true if there are past values on the stack.
+  bool get canUndo;
+
+  /// Will be false if there are future values on the stack.


Should this "false" be "true" or am I misreading it?

justinmc · 2022-08-10T22:35:33Z

packages/flutter/lib/src/widgets/undo_history.dart

+  UndoHistoryController({UndoHistoryValue? value}) : super(value ?? UndoHistoryValue.empty);
+
+  /// Notifies listeners that [undo] has been called.
+  final ChangeNotifier onUndo = ChangeNotifier();


Should these ChangeNotifiers be disposed?

Can it be private? It seems to be a way an API just to wire up the undo/redo to the UndoHistory widget.

Possibly, but I think making it public makes this more useful to consumers, for example, if they are implementing their own version of UndoHistory, they would need to listen to the undo/redo notifications.

justinmc · 2022-08-10T22:36:57Z

packages/flutter/lib/src/widgets/undo_history.dart

Reading through this again I think I'm onboard with UndoHistoryController as-is. It makes a lot of sense in the example you included in the examples directory.

justinmc · 2022-08-10T22:40:15Z

packages/flutter/lib/src/widgets/undo_history.dart

+  }
+
+  @override
+  void handlePlatformUndo(String direction) {


In general I've been thinking about moving away from the pattern of passing raw, privately defined strings around from these platform methods.

Is there a way you could convert this direction to an enum or something that is publicly defined? Then in your tests you could also reference that instead of hardcoded "undo" and "redo" strings that I saw in a few places.

justinmc · 2022-08-10T22:41:37Z

packages/flutter/test/widgets/editable_text_utils.dart

Another nit here: I think that should actually be a doc comment with 3 slashes ///.

justinmc · 2022-08-10T22:42:06Z

packages/flutter/test/widgets/editable_text_utils.dart

By the way, I'm glad sendKeys will be reusable now. I've wanted it in other test files before.

…hanges

chunhtai

left a reply with a suggestion, otherwise this LGTM

chunhtai · 2022-11-30T19:45:17Z

packages/flutter/lib/src/widgets/undo_history.dart

+  /// If the state would still be the same before and after the undo/redo, this
+  /// will not be called. For example, receiving a redo when there is nothing
+  /// to redo will not call this method.
+  final void Function(T value) onTriggered;


I think this may be a corner case that is not so common in real life. I vote for just assert the value should stay the same after this method is called. If this does crash some use case, we can figure out how to handle it later. Also at that point we may have a better picture on how we should support this use case

…e, instead encoding that behavior in _push

justinmc · 2023-01-06T17:36:46Z

@fbcouch Can you update this branch by merging in master? GitHub is saying there is a conflict, though it doesn't say what the conflict is...

Otherwise I think we need to merge this!

jmagman · 2023-01-06T18:12:35Z

Thanks for sticking with this for so long, @fbcouch!

justinmc · 2023-01-06T22:06:02Z

I spoke a little too soon, we should make sure that this comment thread is resolved. I just left a comment explaining the composing text behavior.

… after onTriggered call

fbcouch · 2023-03-07T19:09:02Z

@justinmc @chunhtai I merged main into this branch again, trying to preserve relevant changes to the old TextEditingHistory from #120889, #120062, and #119028

I think we should have everything wrapped up here (see: https://github.com/flutter/flutter/pull/98294/files#r1080613858 )

justinmc

Renewing my LGTM with the latest changes 👍

Thanks for doing all the work to bring this back up to date. I'll plan to merge it tomorrow morning if no one else objects.

justinmc · 2023-03-08T00:34:01Z

packages/flutter/lib/src/widgets/undo_history.dart

+  /// If the state would still be the same before and after the undo/redo, this
+  /// will not be called. For example, receiving a redo when there is nothing
+  /// to redo will not call this method.
+  final void Function(T value) onTriggered;


I tried this out again and it seems to work for me on both iOS and Android with Gboard, where it correctly includes composing state in the undo history. I also tried the example above and got the assertion. Thanks!

Add support for iOS UndoManager

flutter-dashboard bot added a: text input Entering text in a text field or keyboard related problems framework flutter/packages/flutter repository. See also f: labels. labels Feb 11, 2022

fbcouch mentioned this pull request Feb 11, 2022

Add support for iOS UndoManager flutter/engine#31415

Merged

8 tasks

flutter-dashboard bot added the a: tests "flutter test", flutter_test, or one of our tests label Feb 14, 2022

chunhtai self-requested a review February 15, 2022 18:01

fbcouch marked this pull request as ready for review February 16, 2022 17:20

justinmc reviewed Feb 17, 2022

View reviewed changes

chunhtai reviewed Feb 17, 2022

View reviewed changes

fbcouch marked this pull request as draft March 2, 2022 22:32

fbcouch marked this pull request as ready for review March 9, 2022 20:37

flutter-dashboard bot added f: cupertino flutter/packages/flutter/cupertino repository f: material design flutter/packages/flutter/material repository. labels Mar 9, 2022

justinmc reviewed Mar 19, 2022

View reviewed changes

justinmc reviewed Mar 21, 2022

View reviewed changes

justinmc reviewed Apr 29, 2022

View reviewed changes

Implement UndoManager

2c73403

fbcouch force-pushed the feature/undo-redo-gestures branch from c094938 to 2c73403 Compare May 16, 2022 19:27

justinmc reviewed Aug 10, 2022

View reviewed changes

Change UndoManagerClient to mixin, add UndoDirection enum, other PR c…

d9cd837

…hanges

Merge branch 'main' into feature/undo-redo-gestures

403da3d

chunhtai approved these changes Nov 30, 2022

View reviewed changes

Remove duringTrigger variable from the shouldChangeUndoStack signatur…

a26bd35

…e, instead encoding that behavior in _push

fbcouch added 6 commits January 6, 2023 16:51

Merge branch 'main' into feature/undo-redo-gestures

c5e7c09

Adding assertion to ensure value is either the nextValue or lastValue…

722e226

… after onTriggered call

Include composing changes in the undo history

8abe59b

Merge branch 'main' into feature/undo-redo-gestures

49ca399

Fix failing tests

50d96f9

Fix analyze issue

deec8c6

justinmc approved these changes Mar 8, 2023

View reviewed changes

justinmc added the autosubmit Merge PR when tree becomes green via auto submit App label Mar 8, 2023

auto-submit bot merged commit 2a67bf7 into flutter:master Mar 8, 2023

engine-flutter-autoroll mentioned this pull request Mar 9, 2023

Roll Flutter from 5a279edc239f to c5da5070f10e (32 revisions) flutter/packages#3429

Closed

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Mar 9, 2023

2a67bf7 Add support for iOS UndoManager (flutter/flutter#98294)

c801122

engine-flutter-autoroll mentioned this pull request Mar 10, 2023

Roll Flutter from 5a279edc239f to 1f426123230b (53 revisions) flutter/packages#3437

Closed

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Mar 10, 2023

2a67bf7 Add support for iOS UndoManager (flutter/flutter#98294)

0b3d493

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Mar 10, 2023

2a67bf7 Add support for iOS UndoManager (flutter/flutter#98294)

515b5c6

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Mar 10, 2023

2a67bf7 Add support for iOS UndoManager (flutter/flutter#98294)

774a516

hannah-hyj pushed a commit to hannah-hyj/flutter that referenced this pull request Mar 11, 2023

Add support for iOS UndoManager (flutter#98294)

c01e763

Add support for iOS UndoManager

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Mar 11, 2023

2a67bf7 Add support for iOS UndoManager (flutter/flutter#98294)

d06b4d1

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Mar 12, 2023

2a67bf7 Add support for iOS UndoManager (flutter/flutter#98294)

35bb577

HansMuller mentioned this pull request Mar 16, 2023

Flutter Framework Team: Notable Commits #121415

Closed

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request May 10, 2023

2a67bf7 Add support for iOS UndoManager (flutter/flutter#98294)

b308de7

engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request May 10, 2023

2a67bf7 Add support for iOS UndoManager (flutter/flutter#98294)

9da817a

Conversation

fbcouch commented Feb 11, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pre-launch Checklist

Uh oh!

fbcouch commented Feb 14, 2022

Uh oh!

fbcouch commented Feb 16, 2022

Uh oh!

justinmc left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fbcouch commented Feb 17, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fbcouch commented Feb 24, 2022

Uh oh!

fbcouch commented Mar 2, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

justinmc commented Mar 7, 2022

Uh oh!

fbcouch commented Mar 7, 2022

Uh oh!

fbcouch commented Mar 11, 2022

Uh oh!

justinmc commented Mar 18, 2022

Uh oh!

justinmc left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

skia-gold commented Mar 21, 2022

Uh oh!

justinmc left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fbcouch commented Feb 11, 2022 •

edited

Loading

fbcouch commented Mar 2, 2022 •

edited

Loading

justinmc left a comment •

edited

Loading