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.

I am a bit confused, is setMarketTextRect used on macOS? The rect is only valid during compositing, that's why I added setCaretRect in #77608.

@knopp it says

is used for positioning the IME candidates menu

so it's not directly related to the caret I think.

@knopp it says

is used for positioning the IME candidates menu

so it's not directly related to the caret I think.

The IME candidates menu on Mac is displayed on caret position outside of composition mode.

I am a bit confused, is setMarkedTextRect used on macOS? The rect is only valid during compositing, that's why I added setCaretRect in #77608.

We use setMarkedTextRect for IME candidate menu positioning on all platforms other than macOS (and Android) at the moment. The only reason it hasn't been done it that I got pulled away from CJK support for macOS midway through coding up the PR since I was scheduled for engine sheriff rotation, and then to get CppWinRT packaged up as a CIPD package for Windows.

Using the caret position would result in incorrect positioning for the IME candidate menu on macOS, since it needs to be positioned at the bottom-left corner of the composing region, and doesn't move with the caret. That behaviour is platform-specific.

Example of the expected behaviour:

The correct behaviour is actually predicated on implementing #68547, since it's really the active subrange that we care about, not the full composing region.

I see. Wasn't aware of #68547. Thanks for the clarification!

#68547 is interesting since this will affect all platforms once we have proper modelling for it in the framework. It's not an issue for soft keybards, but we'll definitely need it for desktop and iOS with physical keyboards. When I originally added IME support for iOS/Android in 2016, hardware keyboards were pretty low on our list of priorities, unfortunately.

In the meantime, the bottom-left of the composing region is about as close as we can get on platforms like macOS that avoid moving the IME candidate menu.

Added a video to #68547 to give a better idea.