I think it's worth adding a unit test, maybe:

1. Tap on a TextField
2. invoke the engine initiated TextInput.clearClient
3. verify the the framework invoked TextInput.clearClient
4. tap the text field again
5. verify that a client is attached and that the keyboard is showing.

Writing this scenario I realize using the exact same method name TextInput.clearClient for different things on the different channel directions may be a little confusing, maybe consider renaming it on one of the directions.

Writing this scenario I realize using the exact same method name TextInput.clearClient for different things on the different channel directions may be a little confusing, maybe consider renaming it on one of the directions.

@amirh the reason I named it the same was because, as far as I could tell, the "clearClient" request is the same request. The only difference is that the request can now originate from either the framework or the platform. Since both sides maintain state related to an input client, that seemed reasonable to me. Did I miss anything?

PS - I'll try to add the test.

I was just a little confused by that name. In my mental model the framework is the one who's making the decisions regarding the current text client, and the engine is executing whatever the framework says. I feel like it's still the case with the new "clearClient" we added (while the engine could clear the client locally, it notified the framework and waits for the framework to ask for the client to be cleared). Under this mental model I'd maybe call the new method "connectionLost" or maybe something with the word "notify".

Just a suggestion.

After chatting with @xster I'm going to pause this PR to see if we might find a framework-level resolution by way of platform lifecycle events. If not, then I'll return to these PRs, fix them up, and merge them in.

(PR triage): Sound like this needs further discussion? Can we close the PR for now (since it is not really actionable right now) and move the discussion to an issue?

Closing this PR as per @goderbauer's comment. We may need a more holistic solution to this issue. Will follow up once we've figured that out.

After discussion with @xster and @goderbauer I'm re-opening this PR because this approach seems reasonable for the specific issue in question.

I updated the PR with a different approach that utilizes InputConnection#closeConnection() instead of FlutterView destruction. This change in approach now solves the original but, as well as a bug where giving focus to a regular Android View did not result in Flutter UI from losing focus, or clearing of Flutter's input connection.

I also renamed the Android side message from 'clearClient' to 'onConnectionClosed'.

I'm still dubious about where and how I'm invoking unfocus(). If anyone can see a more canonical place to adjust focus, I'd like to hear it.

After some investigating, the failing test is here:
https://github.com/flutter/flutter/blob/master/packages/flutter/test/material/text_field_test.dart#L1015

The specific line in this PR that causes the failure is here:
https://github.com/flutter/flutter/pull/35100/files#diff-2d74aabcc309c260810a6cca572e134eR1225

I'm unclear on the connection between this PR and the failing test so I reached out to @chunhtai for help fixing this PR.

After some investigating, the failing test is here:
https://github.com/flutter/flutter/blob/master/packages/flutter/test/material/text_field_test.dart#L1015

The specific line in this PR that causes the failure is here:
https://github.com/flutter/flutter/pull/35100/files#diff-2d74aabcc309c260810a6cca572e134eR1225

I'm unclear on the connection between this PR and the failing test so I reached out to @chunhtai for help fixing this PR.

When textfield switch from non-readonly to readonly, Textfield will close the input connection if it is present. In your pr, it will listen to the connection close which will also unfocus the editable text and that will cause the selection overlay to be hidden. This is why the test is failing.

The correct behavior is from non-readonly to readonly transition, the input connection should be close, but it should still have focus as the selectionoverlay should still present in readonly mode. Is there a reason why we want to unfocus when the input connection closes?

Is there a reason why we want to unfocus when the input connection closes?

WRT to this PR, the reason for that behavior is that when the input connection closes on the platform, it means that text editing has ended. The keyboard should disappear and any cursor should disappear as well. Otherwise, it looks like the text input is still legitimate even though no input connection exists. My perception of this situation is that the way we should do this is by unfocusing the text field.

Based on the intended behavior that you mentioned, it sounds like a text field should be able to receive focus without an input connection, but I'm surprised by this. Are you sure that's the desired behavior? What does it mean for a text field to be focused if it can't receive text input? And how do we differentiate between situations where we should open a text input connection vs not open a text input connection if focus is unrelated to text input?

Based on the intended behavior that you mentioned, it sounds like a text field should be able to receive focus without an input connection, but I'm surprised by this. Are you sure that's the desired behavior? What does it mean for a text field to be focused if it can't receive text input? And how do we differentiate between situations where we should open a text input connection vs not open a text input connection if focus is unrelated to text input?

It can be focused to receive text selection. and selection (long press on text) does not necessary required an input connection. The reason why we only have selection when it is focused is that we want to hide the selection if the textfield lose focus.

Also, we will eventually need to support keyboard navigation of the selection (e.g. SHIFT RIGHT_ARROW to extend the selection), and in order to get key events from hardware keyboards, the widget needs to be focused.

FocusNodes already have a keyboard token that differentiates between explicit user action and "automatic" focus, and it's up to the widget to consume that token if it wants to open the soft keyboard.

(PR triage): @matthew-carroll Do you still have plans for this PR?

yes

@gspencergoog @chunhtai I removed the explicit unfocus and the existing tests pass again.

It will be good to have a test or two to guard it.

/cc @nturgut

@chunhtai I pushed a Dart test in text_input_test.dart. I attempted to add one at the textfield widget layer, too, but discovered that the way we fake text input makes such a test superfluous. We essentially bypass the channel behavior of text_input, which is the whole point of the test. I chatted with @gspencergoog about this and he also found the same limitation. So I don't think we can test at that level.

Since this was reverted, is there a corresponding issue that this originally fixed that needs to be re-opened?

The issue is still open. I never got around to closing it: #35054

I am still seeing the issue. is there any workaround ?

For posterity, Matt's analysis for the cause of the revert from #39523

For future reference, my current theory is this. On the engine side, we watch for Android closing the input connection so that we can forward that info to Flutter. When I implemented that behavior, I assumed that Android only closed connections when input is truly lost for a given input connection. However, based on carefully watching the Flutter gallery app for its phone number field, I think that what Android does is initially show a regular keyboard, and then Flutter tells Android to switch to a number keyboard, which, I think, causes Android to report the input connection is closed before re-opening the input connection with the new type of keyboard. This may be the root cause of the regression. Maybe the embedding's existing logic for opening an input connection is slightly wrong and needs to be updated.

Has the issue been settled yet