[macOS] TextInputPlugin should not consume unhandled key equivalent events #34250

knopp · 2022-06-23T10:23:17Z

If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.

Pre-launch Checklist

I read the Contributor Guide and followed the process outlined there for submitting PRs.
I read the Tree Hygiene wiki page, which explains my responsibilities.
I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
I listed at least one issue that this PR fixes in the description above.
I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on
writing and running engine tests.
I updated/added relevant documentation (doc comments with ///).
I signed the CLA.
All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

LongCatIsLooong · 2022-06-28T18:25:14Z

shell/platform/darwin/macos/framework/Source/FlutterTextInputPlugin.mm

@@ -482,7 +512,16 @@ - (BOOL)handleKeyEvent:(NSEvent*)event {
    return NO;
  }

-  return [_textInputContext handleEvent:event];
+  _eventProducedOutput = NO;


If the event is a key equivalent, should we let the application route it as a key equivalent first, if it's not handled, then we give the event to the currently focused text field?

Not familiar with how key handling on macOS works so /cc @dkwingsmt

By application do you mean the framework? Because if so that's already happening. On the other hand If you mean the rest of cocoa responder chain, then I'd say no - this would be completely different behavior that what happens without text input (framework first, cocoa second).

The whole purpose of this PR is to make sure that TextInputContext doesn't doesn't simply swallow keyEquivalent events that don't produce any text editing action so that they are forwarded to the rest of responder chain.

I mean the cocoa responder chain (potentially by sending it back to the -[FlutterViewController performKeyEquivalent:] method's super implementation).
-[FlutterTextInputPlugin handleKeyEvent:] is only called when the framework doesn't consume the key event iirc? So it's already "framework first"?

So it's already "framework first"?

It is. This is the main keyboard event processing:

engine/shell/platform/darwin/macos/framework/Source/FlutterKeyboardManager.mm

Lines 198 to 229 in 0cc828c

- (void)performProcessEvent:(NSEvent*)event onFinish:(VoidBlock)onFinish {

if (_viewDelegate.isComposing) {

[self dispatchTextEvent:event];

onFinish();

return;

}

// Having no primary responders require extra logic, but Flutter hard-codes

// all primary responders, so this is a situation that Flutter will never

// encounter.

NSAssert([_primaryResponders count] >= 0, @"At least one primary responder must be added.");

__weak __typeof__(self) weakSelf = self;

__block int unreplied = [_primaryResponders count];

__block BOOL anyHandled = false;

FlutterAsyncKeyCallback replyCallback = ^(BOOL handled) {

unreplied -= 1;

NSAssert(unreplied >= 0, @"More primary responders replied than possible.");

anyHandled = anyHandled || handled;

if (unreplied == 0) {

if (!anyHandled) {

[weakSelf dispatchTextEvent:event];

}

onFinish();

}

};

for (id<FlutterKeyPrimaryResponder> responder in _primaryResponders) {

[responder handleEvent:event callback:replyCallback];

}

}

Primary responders are FlutterEmbedderKeyResponder and FlutterChannelKeyResponder (framework). If these don't handle keyboard event, the event is passed to [FlutterKeyboardManager dispatchTextEvent:]. This will let the TextInputPlugin process event, and if not handled will forward it to nextResponder.

The issue this PR fixes is that any event sent to TextInputPlugin (with active context) was marked as handled, even if it was keyboard shortcut that didn't result in any action.

Yes, FlutterTextInputPlugin#handleKeyEvent is called only when the Framework's keyboard systems choose not to handle the event.

justinmc

Just a few small comments. The approach looks right to me, but curious about @LongCatIsLooong's response to the discussion at https://github.com/flutter/engine/pull/34250/files#r908880528.

shell/platform/darwin/macos/framework/Source/FlutterTextInputPlugin.mm

dkwingsmt · 2022-07-01T10:35:56Z

shell/platform/darwin/macos/framework/Source/FlutterTextInputPlugin.mm

@@ -482,7 +512,16 @@ - (BOOL)handleKeyEvent:(NSEvent*)event {
    return NO;
  }

-  return [_textInputContext handleEvent:event];
+  _eventProducedOutput = NO;
+  BOOL res = [_textInputContext handleEvent:event];


I kind of know what you're changing here in the context of this PR, but if I'm reading the code the following comment confuses me. Can you add more information and describe it in the positive way, like:

NSTextInputContext#handleEvent returns YES if the context handles the event. One of the reasons the event is handled is because it's a key equivalent. But a key equivalent might produce a text command (indicated by calling doCommandBySelector) and might not (for example, Cmd+Q). In the latter case, this command somehow has not been executed yet and Flutter must dispatch it to the next responder. See flutter/flutter#106354 .

dkwingsmt · 2022-07-01T10:41:50Z

I'm ok with this PR. I'm still confused by why NSTextInputContext:handleEvent returns YES for Cmd-Q while not handling it immediately, but I guess that's how it is. A few comment suggestion. Rephrase them as you see fit.

knopp · 2022-07-05T13:05:08Z

@dkwingsmt, I've updated the comment according to your suggestion. Is there anything else or is this good to go?

dkwingsmt

LGTM.

shell/platform/darwin/macos/framework/Source/FlutterTextInputPlugin.mm

justinmc

LGTM 👍

shell/platform/darwin/macos/framework/Source/FlutterTextInputPlugin.mm

shell/platform/darwin/macos/framework/Source/FlutterTextInputPluginTest.mm

…vents

…lugin.mm Co-authored-by: Tong Mu <[email protected]>

…valent events (flutter/engine#34250)

flutter-dashboard bot added the platform-macos label Jun 23, 2022

knopp mentioned this pull request Jun 23, 2022

[macOS] Cannot quit app with Cmd+Q when text field is focused flutter/flutter#106354

Closed

knopp requested a review from justinmc June 23, 2022 14:54

gspencergoog mentioned this pull request Jun 23, 2022

[MacOS] TextField still have focus after user switch to another application flutter/flutter#106323

Closed

knopp requested a review from LongCatIsLooong June 23, 2022 18:34

LongCatIsLooong requested a review from dkwingsmt June 28, 2022 18:07

LongCatIsLooong reviewed Jun 28, 2022

View reviewed changes

knopp mentioned this pull request Jun 30, 2022

[macOS] Remove isComposing workaround #33838

Merged

8 tasks

justinmc reviewed Jun 30, 2022

View reviewed changes

dkwingsmt reviewed Jul 1, 2022

View reviewed changes

shell/platform/darwin/macos/framework/Source/FlutterTextInputPlugin.mm Show resolved Hide resolved

dkwingsmt reviewed Jul 1, 2022

View reviewed changes

knopp force-pushed the cmd_q_in_text_field_not_working branch from 4a16700 to 9aa4a7b Compare July 5, 2022 13:02

dkwingsmt approved these changes Jul 6, 2022

View reviewed changes

shell/platform/darwin/macos/framework/Source/FlutterTextInputPlugin.mm Outdated Show resolved Hide resolved

shell/platform/darwin/macos/framework/Source/FlutterTextInputPlugin.mm Outdated Show resolved Hide resolved

justinmc approved these changes Jul 6, 2022

View reviewed changes

knopp and others added 9 commits July 6, 2022 21:08

[macOS] TextInputPlugin should not consume unhandled key equivalent e…

b32f6bd

…vents

eventProducedCommand -> eventProducedOutput

3ed80fe

Update shell/platform/darwin/macos/framework/Source/FlutterTextInputP…

7a678e6

…lugin.mm Co-authored-by: Tong Mu <[email protected]>

Update shell/platform/darwin/macos/framework/Source/FlutterTextInputP…

c079205

…lugin.mm Co-authored-by: Tong Mu <[email protected]>

Update comment

66e1597

Improve comment

12e6d17

Update shell/platform/darwin/macos/framework/Source/FlutterTextInputP…

7102d2c

…lugin.mm Co-authored-by: Tong Mu <[email protected]>

Update shell/platform/darwin/macos/framework/Source/FlutterTextInputP…

bda942c

…lugin.mm Co-authored-by: Tong Mu <[email protected]>

Update comments

3079907

knopp force-pushed the cmd_q_in_text_field_not_working branch from 46a20ea to 3079907 Compare July 6, 2022 19:08

knopp merged commit 628735f into flutter:main Jul 7, 2022

knopp deleted the cmd_q_in_text_field_not_working branch July 7, 2022 13:00

engine-flutter-autoroll mentioned this pull request Jul 7, 2022

Roll Flutter Engine from 56faff459eb9 to 628735f6f3cb (1 revision) flutter/flutter#107236

Merged

engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Jul 7, 2022

628735f [macOS] TextInputPlugin should not consume unhandled key equi…

19809b1

…valent events (flutter/engine#34250)

	- (void)performProcessEvent:(NSEvent*)event onFinish:(VoidBlock)onFinish {
	if (_viewDelegate.isComposing) {
	[self dispatchTextEvent:event];
	onFinish();
	return;
	}

	// Having no primary responders require extra logic, but Flutter hard-codes
	// all primary responders, so this is a situation that Flutter will never
	// encounter.
	NSAssert([_primaryResponders count] >= 0, @"At least one primary responder must be added.");

	__weak __typeof__(self) weakSelf = self;
	__block int unreplied = [_primaryResponders count];
	__block BOOL anyHandled = false;

	FlutterAsyncKeyCallback replyCallback = ^(BOOL handled) {
	unreplied -= 1;
	NSAssert(unreplied >= 0, @"More primary responders replied than possible.");
	anyHandled = anyHandled \|\| handled;
	if (unreplied == 0) {
	if (!anyHandled) {
	[weakSelf dispatchTextEvent:event];
	}
	onFinish();
	}
	};

	for (id<FlutterKeyPrimaryResponder> responder in _primaryResponders) {
	[responder handleEvent:event callback:replyCallback];
	}
	}

[macOS] TextInputPlugin should not consume unhandled key equivalent events #34250

[macOS] TextInputPlugin should not consume unhandled key equivalent events #34250

Uh oh!

Conversation

knopp commented Jun 23, 2022

Pre-launch Checklist

Uh oh!

LongCatIsLooong Jun 28, 2022

Choose a reason for hiding this comment

Uh oh!

LongCatIsLooong Jun 28, 2022

Choose a reason for hiding this comment

Uh oh!

knopp Jun 28, 2022

Choose a reason for hiding this comment

Uh oh!

knopp Jun 28, 2022

Choose a reason for hiding this comment

Uh oh!

LongCatIsLooong Jun 28, 2022

Choose a reason for hiding this comment

Uh oh!

knopp Jun 28, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dkwingsmt Jul 1, 2022

Choose a reason for hiding this comment

Uh oh!

justinmc left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dkwingsmt Jul 1, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dkwingsmt commented Jul 1, 2022

Uh oh!

knopp commented Jul 5, 2022

Uh oh!

dkwingsmt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

justinmc left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

knopp Jun 28, 2022 •

edited

Loading

dkwingsmt Jul 1, 2022 •

edited

Loading