/cc @fbcouch my apologies, I totally forgot the pull request was a breaking change. Could you write a migration guide for the TextInutClient change (template), and I'll try to migrate our internal code following the guide?

@LongCatIsLooong Is it breaking? I know it changes the interface, but the changes should be optional. I can still take a look at the migration guide.

Yeah there's a class that implements the interface that needs to be updated. I can do that once the pull request relands.

Yeah there's a class that implements the interface that needs to be updated. I can do that once the pull request relands.

Our breaking change policy requires that downstream clients be adjusted (if necessary) before patches land, so that patches can always land cleanly without every breaking any customer tests (including google3).

@LongCatIsLooong flutter/website#6679

I am curious where that implementer is – the only ones that I saw were updated as part of the PR (FakeAutofillClient and FakeTextInputClient)

I am curious where that implementer is – the only ones that I saw were updated as part of the PR (FakeAutofillClient and FakeTextInputClient)

@fbcouch It's our internal proprietary codebase.

Our breaking change policy requires that downstream clients be adjusted (if necessary) before patches land, so that patches can always land cleanly without every breaking any customer tests (including google3).

@Hixie what's the best way to introduce new methods on an existing interface before landing the patch? I thought we use g3fix for things like this?

@LongCatIsLooong Gotcha. I saw an example here where they created a temporary additional class to provide the missing members, so we could do something similar:

class _TemporaryTextInputClient {
  void showToolbar() {}

  void insertTextPlaceholder(Size size) {}

  void removeTextPlaceholder() {}
}

Do you want me to add that to the migration guide?

@Hixie what's the best way to introduce new methods on an existing interface before landing the patch? I thought we use g3fix for things like this?

g3fix is for things like updating BUILD files or fixing flutter_tools, not for breaking change policy fixes.

You might be able to add a method using //ignore on the @override, or changing the code to use extends instead of implements so that it gets the default implementation, or providing a mixin that provides default methods (land the mixin, then update the code to use the mixin, then land the patch adding the method to the mixin and the interface).

@fbcouch iirc that's a temporary workaround for the delta text input client so I would say we should avoid doing that again. I have a pull request out to replace the TextInputClient static interface so that adding new capabilities to the new text fields won't be breaking changes but it looks like that will take some more time to land. I think the migration guide can briefly explain what the new methods are for and say if you don't need scribble support then just provide an empty implementation.

@Hixie ah ok good to know! hopefully I'll be able to land my intent pull request and get rid of the TextInputClient implementer in our internal code, so I'm planning to do the //ignore trick.

@LongCatIsLooong The breaking change page / migration guide was merged in – let me know how the internal migration goes and what (if anything) I need to do next to re-land the PR

Feel free to open a reland pull request, I'll run the internal tests when the migration is done and hopefully merge the pull request. Thank you for the migration guide!