Windows: suggestion window jumps above/below the preedit on every keystroke near the bottom of the screen #1608

Description

On Windows, when typing in a text field near the bottom of the screen, the suggestion window moves between below and above the preedit as you type.

WindowUtil::GetWindowRectForMainWindowFromPreeditRectHorizontal() puts the window above the preedit only when the current window does not fit below. The height of the suggestion window changes with the number of suggestions (1 to 3 rows by default), so near the bottom of the screen it fits below with 1 row and does not fit with 3 rows. The window flips every time the number of suggestions changes.

Steps to reproduce

Steps to reproduce the behavior:

1. Move a Notepad window down so that the line with the caret is just above the taskbar: there should be room below it for a 1-row suggestion window but not for a 3-row one (roughly 50-90 px at 100% scaling). A chat input box at the bottom of a maximized window is often in this range too.
2. Type Japanese text with Mozc so that the number of suggestions changes between keystrokes (e.g. type a long phrase character by character).
3. Watch the suggestion window.

Expected behavior

While typing on the same line, the suggestion window stays on one side of the preedit.

Actual behavior

The suggestion window is shown below the preedit when there is 1 suggestion and above it when there are 2 or 3, so it jumps up and down while typing.

Screenshots

Both taken in the same chat input box at the bottom of the screen.

3 suggestions: the window is shown above the preedit.

1 suggestion: the window is shown below the preedit.

Video: typing character by character in the same input box. The window moves above and below the preedit as the number of suggestions changes. The video was recorded with Google Japanese Input (GoogleJapaneseInput-3.34.6260.0+24.11.9), which shows the same behavior, because my Mozc build already has the fix described below.

Version or commit-id

3.35.6354.100, built from f183d4d with #1607 applied (#1607 does not change window placement).

Environment

• OS: Windows 11 Pro (x64)
• IMF (for Linux): N/A
• Related Applications: a chat input box placed at the bottom of a maximized window

Investigations

• Whether this issue happens on both Ibus and other IMF (e.g. Fcitx, uim).
  • N/A (Windows)
• Whether this issue happens on other IMEs (e.g. Anthy, SKK).
  • yes, on Google Japanese Input 3.34.6260.0 (see the video)
• What applications this issue happens on (e.g. Chromium, gedit).
  • any text field near the bottom of the screen (the placement logic does not depend on the application)
• What applications this issue does not happen on (e.g. Chromium, gedit).
  • text fields with enough room below for a full suggestion window
• (optional) What versions or commit-ids this issue did not happen on.
  • no-investigation

Additional context

This layout, a text box at the bottom of a maximized window, is common in chat apps and AI assistant apps, where people often type long Japanese text. So this happens quite often in daily use.

A possible fix: for commands::SUGGESTION, decide the side using the height of a full suggestion window (3 rows) instead of the current one, so the window does not change sides while the number of suggestions changes. Conversion windows would keep the current behavior.

I tried this on my fork (together with drawing the window upside down when it is above, which I will propose separately in Discussions): nameless911@12f6d8cd
I can send a pull request for the placement part only if this direction is acceptable.