Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check for both compose string and result string. #29620

Merged
merged 5 commits into from
Nov 12, 2021

Conversation

gspencergoog
Copy link
Contributor

@gspencergoog gspencergoog commented Nov 9, 2021

Description

It turns out that unlike the Microsoft IME, Sogou sends a single IME_COMPOSITION message that has both the GCS_COMPSTR and GCS_RESULTSTR flags set, and we check for a composition string before result string, with an "else" clause to check for the result string, so if GCS_COMPSTR is set, we never check for a result string.

Related Issues

@flutter-dashboard
Copy link

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@gspencergoog
Copy link
Contributor Author

I'm trying to write a test for this.

@gspencergoog gspencergoog force-pushed the fix_sogou_ime branch 3 times, most recently from c62330a to c3ca85c Compare November 10, 2021 16:03
Copy link
Member

@cbracken cbracken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good modulo one comment. I'm fine with us fixing that up later in order to get this issue fixed, but would be good to file a bug and add a TODO in that case.

Also, looks like there are a couple cases where mock expectations are not met, causing the test to fail.

@@ -217,6 +217,9 @@ class WindowWin32 {
// Used to process key messages. Exposed for dependency injection.
virtual uint32_t Win32MapVkToChar(uint32_t virtual_key);

// Accessor so that it can be mocked in tests.
virtual TextInputManagerWin32* get_text_input_manager();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we could do this via injection instead? That would avoid adding a public method here and avoid the possibility of someone accidentally breaking things by using that raw private var in some future change to WindowWin32, and potentially FlutterWindowWin32.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I agree that the temptation of using the raw private is possibly bad: I'll redo it as injection. I did think about injection as an option, but the mocking framework wanted to use pointers, and I didn't want to have to inject a heap allocated object, and passing mutable references seems like bad form. I'll probably inject it as a unique_ptr.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds perfect. Thanks!

Copy link
Member

@cbracken cbracken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re-lgtm!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants