CC @LongCatIsLooong is it right that autofill should be only done for the current control?

I'm still not 100% sure about it, but I have considered autofill a visual thing because the TextInputConnection.requestAutofill() documentation states:

Requests the system autofill UI to appear.

Thank you for the review!

I'm interested in @LongCatIsLooong's opinion from an autofill perspective.

I noticed this comment in TextInputConnection.requestAutofill() docs:

Requests the system autofill UI to appear.

It would be a problem if multiple text input controls tried to show autofill UI, which is why I ended up placing the autofill functionality to TextInputControl instead of TextInputHandler.

(PR triage): @jpnurmi @LongCatIsLooong @justinmc Are there still plans for this before it becomes too stale?

I'll get back to this. I was waiting for comments/feedback because I hadn't noticed the thumbs up above.

@jpnurmi Can you fix the conflicts with master? Sorry, that's probably our fault for not giving you a final review fast enough.

There's a failure but it looks like an infrastructure problem, rerunning...

Is there anything I could do to get things rolling?

Sorry for the delay. Looks good to me in general.

Hi @mdebbar would you like to take a look at this? I think this change may have implications on the web.

This PR is based on the idea that the show() and hide() methods are only called on the currently active text input control. This way, only one keyboard pops up. However, Flutter for Web requires show() to be called, or else it won't enter the editing state at all:

https://github.com/flutter/engine/blob/eb658e840d92ab4e8a9862e912ab6a4351f5aa90/lib/web_ui/lib/src/engine/text_editing/text_editing.dart#L1414

In other words, installing a custom text input control on Web blocks platform text input e.g. physical keyboard.

Would it be an option to change it so that the editing state is controlled from setClient() and clearClient() instead, and only editing focus is set from show()?

https://github.com/flutter/engine/blob/eb658e840d92ab4e8a9862e912ab6a4351f5aa90/lib/web_ui/lib/src/engine/text_editing/text_editing.dart#L1000

A potential web-compatible solution:

• introduce TextInputType.none in flutter/services
• when a custom text input control is in use, pass "none" in the text input configuration to the platform text input control
• adapt the engine for all platforms:
  • web: set the "inputmode" attribute to "none"
  • others: don't show the keyboard when the input type is "none"
• bonus: it will be possible to disable the keyboard for individual TextFields

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode

Experimental engine changes for Linux: jpnurmi/engine@387e5c4

@justinmc thank you! 🎉

@itsjustkevin so this PR got removed and no follow up? Why does it break? We are longing for this feature.

@itsjustkevin @jpnurmi Can we/the community help on the related issues on why it causes breakages?

@Eerey I wasn't aware of the revert but notice that it was closed without merging. TextInputControl still exists in the latest main branch:

@itsjustkevin What was the problem? Is this change still causing issues somewhere or was it a false alarm?

This was a breaking change. I'm not sure why this PR didn't fail on the customer testing shard, but it is now blocking Engine rolls into the framework. See: #113666. In particular super_editor is failing due to https://github.com/superlistapp/super_editor/blob/main/super_editor/lib/src/default_editor/document_input_ime.dart#L75.