Provide default method call handler for SystemChannels.textInput #101087
Conversation
…hat TextInput.requestElementsInRect can return immediately, even before TextInput initialization
flutter-dashboard
bot
added
the
framework
|
/cc @justinmc @LongCatIsLooong who reviewed #75472 |
| SystemChannels.system.setMessageHandler((dynamic message) => handleSystemMessage(message as Object)); | ||
| SystemChannels.lifecycle.setMessageHandler(_handleLifecycleMessage); | ||
| SystemChannels.platform.setMethodCallHandler(_handlePlatformMessage); | ||
| SystemChannels.textInput.setMethodCallHandler((MethodCall call) => Future<void>.value()); |
There was a problem hiding this comment.
This looks very odd - and hopefully isn't the real fix here. If it is, this will need a comment explaining what's going on.
There was a problem hiding this comment.
With Scribble I think one will be able to enter text when TextInput._instance isn't initialized, so the text input plugin now may start the communication (before that the communication starts when a text field gains focus). So I guess we can do this, or use a separate method channel for Scribble.
There was a problem hiding this comment.
Also I suspect flutter iPad Scribble does not work until the first text field gains focus, because TextInput._instance is lazily initialized?
There was a problem hiding this comment.
So the issue is that the indirect scribble interaction is set up on the engine side, but with nothing on the framework side handling messages on the textinput channel yet, there are a few moments where iPadOS isn't sure whether a scribble interaction is going to happen or not, so it swallows the inputs and shows a little pencil streak.
If there's a default handler on the method channel, as here, then that doesn't happen because the engine gets a very fast reply over the channel and can let iPadOS know that there won't be a scribble interaction occurring.
I suppose an alternative solution might be to wait to add the UIIndirectScribbleInteraction until we get a message from the framework over the channel...I think that might work in 2.12, since it no longer waits for focus to set up the TextInput._instance.
If this is acceptable, though, I can try to distill that down into something appropriate for a comment.
There was a problem hiding this comment.
I think that might work in 2.12, since it no longer waits for focus to set up the
TextInput._instance.
Ah I see TextInput is accessed in initState.
I would slightly prefer setting up the method handler eagerly over waiting for the first incoming message in the engine ( "first incoming message == we have a framework method channel handler" is kinda of a framework implementation detail). @goderbauer suggestions for making it less odd? Maybe we can expose a TextInput.ensureInitialized method and call that?
There was a problem hiding this comment.
I don't fully understand how the scribble feature works, but it is odd that the engine sends us a message and we just drop it on the floor. We should either set up the correct message handler here and handle the message or change the engine side to not send these over the channel until the framework can actually handle them.
|
(Triage) @fbcouch Do you still have plans to follow up on this PR? |
Yes, thank you for the reminder! I updated the above to add a |
There was a problem hiding this comment.
This solution looks nice to me compared to the original one, but @LongCatIsLooong should get a final look.
| SystemChannels.system.setMessageHandler((dynamic message) => handleSystemMessage(message as Object)); | ||
| SystemChannels.lifecycle.setMessageHandler(_handleLifecycleMessage); | ||
| SystemChannels.platform.setMethodCallHandler(_handlePlatformMessage); | ||
| TextInput.ensureInitialized(); |
There was a problem hiding this comment.
Any negative impact of this if an app doesn't use text input at all?
There was a problem hiding this comment.
I think the only negative would be whatever small amount of memory the TextInput instance consumes
|
When does this PR land in stable? It is very frustrating having no clue when this critical issue would be solved in stable. I have no chance to use the stable version right now and have to roll back to an earlier version of flutter to just make it work.. |
On the iPad, starting with flutter 2.10, the engine sets up a
UIIndirectScribbleInteractionand attempts to communicate with the framework over theflutter/textinputchannel when a Scribble interaction begins (see flutter/engine#24224). However, before that channel has a method call handler, the engine does not get a reply, so iPadOS continues sending pencil input to the Scribble feature, rather than allowing flutter to capture the input.Adding a default method call handler allows the engine to get a
nullreply immediately, so that iPadOS can finish the Scribble interaction and allow input to flow back to flutter.TextInputwill set it's own handler once instantiated, so this does not appear to interfere with normal text input.Fixes #101016
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.