-
Notifications
You must be signed in to change notification settings - Fork 361
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
Comments
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
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
Summary
Environment
How to setup the environment to reproduce
Steps to reproduce
Expected behaviorAfter the step 2, both suggestion window and conversion window should respect the rectangle specified by Firefox with Actual behaviorAfter the step 2, both suggestion window and conversion window do not respect the rectangle specified by Firefox with Internal Issue ID: |
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):
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.
The text was updated successfully, but these errors were encountered: