Repository navigation
[macOS] TextField lost input event after composing text deleted #100272
Description
Noticed that #78061 has been fixed, but there seems to be a small problem here.
Steps to Reproduce
- Execute
flutter runon the code sample - type Chinese by PinYin input method.
for example: type nihao
- press
backspaceto delete all composing text in floating view. - when all composing text be deleted, this
TextFieldcan not input number, character any more.
Expected results:
Actual results:
2022-03-17.10.38.28.mov
Code sample
import 'package:flutter/material.dart';
void main() {
runApp(const MyApp());
}
class MyApp extends StatelessWidget {
const MyApp({Key? key}) : super(key: key);
// This widget is the root of your application.
@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'Flutter Demo',
theme: ThemeData(
primarySwatch: Colors.blue
),
home: const _HomePage(),
);
}
}
class _HomePage extends StatelessWidget {
const _HomePage({ Key? key }) : super(key: key);
@override
Widget build(BuildContext context) {
return const Scaffold(
body: Center(
child: TextField(),
),
);
}
}Logs
➜ my_app flutter --version
Flutter 2.13.0-0.0.pre.114 • channel master •
https://github.com/flutter/flutter.git
Framework • revision b4040c867b (15 minutes ago) • 2022-03-17 10:15:13 +0800
Engine • revision 46c2ccae24
Tools • Dart 2.17.0 (build 2.17.0-202.0.dev) • DevTools 2.11.4
Activity
cbracken commentedon Mar 17, 2022
/cc @LongCatIsLooong (and myself)
cbracken commentedon Mar 17, 2022
This also reproduces with macOS Japanese - Romaji input method.
To be very slightly more specific with the repro steps:
Expected behaviour: composing region now contains the character typed (e.g. 'n')
Actual behaviour: composing region contains nothing, IME candidate menu pops up at screen position (0,0), but contains the correct composing text.
I haven't tried debugging this, but I suspect that we've got an off-by-one error in how we set the composing state. In other words, we're leaving TextInputModel in composing mode after the last character is deleted, or we're failing to begin composing and activate the IME once the first new character is typed after deleting all text in the composing range.
A couple more hints at what's going on here:
TextInputModel.LongCatIsLooong commentedon Mar 18, 2022
The
NSTextInputContextwe use in the text input plugin seems to be deactivating itself whenever the composing region is deleted, without even callingNSTextInputContext.deactive. There's aNSTextInputContext.isActiveprivate method that can be used to confirm this.The right fix seems to be properly incorporate
FlutterTextInputPlugininto the responder chain (or view hierarchy), and make it the primary focus when it's supposed to be taking input. But I think the change is going to be substantial. Calling[_textInputContext activate]before[_textInputContext handleEvent:]also seems to work but it's quite hacky.cbracken commentedon Mar 22, 2022
This was resolved in flutter-team-archive/engine#32117.
LongCatIsLooong commentedon Mar 22, 2022
@cbracken I was planning to repurpose this issue for properly setting up the responder chain on macOS for text input. Should I create a new issue instead?
LongCatIsLooong commentedon Mar 22, 2022
Created #100590
cbracken commentedon Mar 23, 2022
Ah thanks; this was listed on the stable blockers dashboard and had moved it to done. Thanks for creating a new issue for the proper strategic fix for this!
github-actions commentedon Apr 6, 2022
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.