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

ImmSetCandidateWindow() with CFS_EXCLUDE isn't supported on Win Vista and Win7 #361

Closed
masayuki-nakano opened this issue Jan 28, 2016 · 1 comment · Fixed by #365
Closed

Comments

@masayuki-nakano
Copy link

As far as I know, Google Japanese Input is installed as IMM-IME. Actually, when I use it on Firefox which is TSF-aware, Google Japanese Input doesn't work with TSF APIs (e.g., ITextStoreACP).

Firefox uses CFS_EXCLUDE for specifying candidate window position in horizontal layout mode. However, this won't work will with Google Japanese Input on Win Vista and Win7. I know it shouldn't work on Win8 or later because Google Japanese Input is installed as TSF-TIP and CUAS doesn't support CFS_EXCLUDE when applications call ImmSetCandidateWindow().

You can test this with following steps (I tested with Google Japanese Input 2.17.2400.0):

  1. Load https://bug1243268.bmoattachments.org/attachment.cgi?id=8713081 with Firefox on Win Vista or Win7
  2. Type "わたしのなまえはなかのです"
  3. Convert it until candidate window is shown

Firefox specifies CFS_EXCLUDE whose rect includes whole selected clause in the composition string. So, the selected clause shouldn't be overlapped with candidate window but Google Japanese Input show it under first character of the selected clause.

This bug is very annoying if the editor is vertical writing mode.

I cannot reproduce this bug with Google Japanese Input 1.13.1641 on WinXP.

yukawa added a commit that referenced this issue Mar 13, 2016
It turns out that |CANDIDATEFORM::rcArea| has been unexpectedly ignored
when the IMM32 client also supports IMR_QUERYCHARPOSITION protocol.

In short, the base position and exclude region for suggestion/conversion
window should be determined by using different priority rules.

Followings are expected orders of rules after this CL is applied.

 A. base position for suggestion:
  1. IMR_QUERYCHARPOSITION
  2. CANDIDATEFORM::ptCurrentPos (if CAN_USE_CANDIDATE_FORM_FOR_SUGGEST)
  3. GUITHREADINFO::rcCaret
  4. COMPOSITIONFORM::ptCurrentPos
  5. The edge of the client window.

 B. base position for conversion:
  1. IMR_QUERYCHARPOSITION
  2. CANDIDATEFORM::ptCurrentPos
  3. GUITHREADINFO::rcCaret
  4. COMPOSITIONFORM::ptCurrentPos
  5. The edge of the client window.

 C. exclude rect for suggestion:
  1. CANDIDATEFORM::rcArea (if CAN_USE_CANDIDATE_FORM_FOR_SUGGEST)
  2. IMR_QUERYCHARPOSITION + font height
  3. GUITHREADINFO::rcCaret + font height
  4. COMPOSITIONFORM::ptCurrentPos + font height
  5. The client rect of the target window.

 D. exclude rect for conversion:
  1. CANDIDATEFORM::rcArea
  2. IMR_QUERYCHARPOSITION + font height
  3. GUITHREADINFO::rcCaret + font height
  4. COMPOSITIONFORM::ptCurrentPos + font height
  5. The client rect of the target window.

What has been broken is the 1st rule and 2nd rule of C and D.
Previously we have mistakenly put higher priority on
IMR_QUERYCHARPOSITION in those cases.

BUG=#361
TEST=manually done
REF_BUG=27394949
REF_CL=115815290
yukawa added a commit that referenced this issue Mar 13, 2016
Strictly speaking, IMM32 spec never requires the application to update
|CANDIDATEFORM| until IMN_OPENCANDIDATE is sent from the IME.

In the case of Mozc, we intentionally do not send IMN_OPENCANDIDATE when
the suggestion window is shown, because doing that can confuse some
applications such as command prompt.

That said, |CANDIDATEFORM::rcArea| is still a useful information that we
want to rely on if it is guaranteed to be kept updated.  For that
purpose, we have maintained a list of applications which are known to
keep |CANDIDATEFORM::rcArea| updated regardless of IMN_OPENCANDIDATE,
and this CL adds "MozillaWindowClass" window class into the whitelist so
that Firefox can be marked with CAN_USE_CANDIDATE_FORM_FOR_SUGGEST
compatibility flag.

BUG=#361
TEST=manually done
REF_BUG=27394949
REF_CL=115815738
@yukawa yukawa self-assigned this Mar 13, 2016
@yukawa
Copy link
Collaborator

yukawa commented Mar 13, 2016

Summary

mozc_renderer unexpectedly ignores CANDIDATEFORM::rcArea when the target application supports IMR_QUERYCHARPOSITION protocol.

Environment

  • Mozc 2.17.2320.100 and prior (built for IMM32)
  • Firefox Nightly (32-bit) 48.0a1 (2016-03-12)
  • Windows 10 1511 (OS Build 10586.122)

How to setup the environment to reproduce

  1. Build Mozc for Windows as explained in How to build Mozc in Windows
  2. Install Mozc for Windows as IMM32 client as explained in Register Mozc for IMM32 into 64-bit environment

Steps to reproduce

  1. Load https://bug1243268.bmoattachments.org/attachment.cgi?id=8713081 with Firefox Nightly 48.0a1 (2016-03-12)
  2. Type "わたしのなまえはなかのです"

Expected behavior

After the step 2, both suggestion window and conversion window should respect the rectangle specified by Firefox with CANDIDATEFORM::rcArea.
mozc_issue361_expected

Actual behavior

After the step 2, both suggestion window and conversion window do not respect the rectangle specified by Firefox with CANDIDATEFORM::rcArea.
mozc_issue361_actual

Internal Issue ID: 27394949.

@yukawa yukawa mentioned this issue Mar 13, 2016
yukawa added a commit that referenced this issue Mar 13, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants