Fix requestExistingInputState response#47472
Fix requestExistingInputState response#47472fluttergithubbot merged 2 commits intoflutter:masterfrom
Conversation
|
@Hixie - this is an example of a breaking change that will be really hard to make soft. We have an internal customer who implements the interface I want to change. I could make it a soft break in a really ugly way by adding the new field to a subclass, checking if I have that subclass, and if not doing something to alert the developer that they're going to lose state when the app is backgrounded on Android. That seems wrong to me. We'd be writing code that's really ugly and hard to understand, e.g.: While the migration is actually fairly simple, and the usage of this interface is very limited. |
|
I'm going to make this a soft migration for the internal client by patching them to have the new value as an override with a temporary interface that we'll delete once this rolls. |
|
xref cl/286430188 and b/146568373 |
| assert(_currentConnection._client != null); | ||
| _attach(_currentConnection, _currentConfiguration); | ||
| // This will be null if we've never had a call to [_setEditingState]. | ||
| if (_currentTextEditingValue != null) { |
There was a problem hiding this comment.
I wonder if the code would be a little bit clearer leaving this if outside the _attach method. The setEditingState seems like kinda a strange parameter to that method.
There was a problem hiding this comment.
Sure - it seemed a little awkward to me either way but this way it'll be closer to the actual use case for it.
There was a problem hiding this comment.
Actually redoing this uncovered a potential bug (TextEditingValue can be null).
|
This should wait for the internal CL to land first in case it gets grabbed by a roll soon |
Description
#47177 attempted to fix this issue by more frequently calling
setEditingState. This resulted in races/contention between the framework and platform side about who owned the editing state value, and caused failures on some Espresso based tests. I'm adding some tests to make sure that behavior is more clearly exercised in #47464Related Issues
#47177 Was a different attempt to fix this.
#43959 Was where a lot of this code was originally introduced.
Fixes #47137.
Tests
I added the following tests:
Removed a test that isn't valid - we shouldn't be using setEditingState that way.
Updated a test to use the new property on
TextEditingClient.Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]). This will ensure a smooth and quick review process.///).flutter analyze --flutter-repo) does not report any problems on my PR.Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.