Need Level 3 IME Support on winxp for MS PinYin v3 ime

VERIFIED FIXED in mozilla1.0.2

Status

()

Core
Internationalization
P1
major
VERIFIED FIXED
16 years ago
8 years ago

People

(Reporter: Jaime Rodriguez, Jr., Assigned: Roy Yokoyama)

Tracking

({inputmethod, intl, topembed+})

Trunk
mozilla1.0.2
x86
Windows XP
inputmethod, intl, topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2] [ETA 09/23])

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

16 years ago
Need to better support Level 3 IME.

ftang: pls add further information on this issue, based on conversations and
needs of the customer.

Updated

16 years ago
Keywords: intl

Comment 1

16 years ago
Can you provide some more explanation?  It sound like a request for enhancement
although I have no idea what IME is.....  Etc...

Comment 2

16 years ago
Below are info received from 
Ben Morrell Gordon

Here is the bug:
Microsoft has confirmed that the MSPinYin 3.0 IME (WindowsXP) does not properly
respond to the ImmSetCandidate... APIs.

However, I have found that by default MSPinYin IME will set candidate window
position properly, by following cursor/caret pos.

The problem occurs when trying to explicitly set the position of the
caret/cursor in an edit widget after responding to the IMEs SetCursorPos flag
(in a WM_COMPOSITION msg).

The fix (in our case,) was to only honor SetCursorPos flag (in a WM_COMPOSITION
msg), when we were actually inserting text when recieving this message.

The problem appears to be related to an edit widgets management of the
caret/cursor in relation to when the IME try to determine the caret position.

Roy, please take a look at this
Assignee: ftang → yokoyama
Keywords: topembed
Priority: -- → P2
Summary: Need Level 3 IME Support → Need Level 3 IME Support on winxp for MS PinYin v3 ime

Updated

16 years ago
Blocks: 154896

Comment 3

16 years ago
roy- any progress?
(Reporter)

Comment 4

16 years ago
Marking as topembed+ as this is needed by a major embeddor.
Severity: normal → major
Keywords: topembed → nsbeta1+, topembed+
Priority: P2 → P1
Whiteboard: [adt2] [ETA Needed]
Target Milestone: --- → mozilla1.0.2
(Reporter)

Updated

16 years ago
Keywords: mozilla1.0.2, mozilla1.2
(Assignee)

Comment 5

16 years ago
Created attachment 100343 [details]
simple app to exhibit the ime problem. (zip format)

We tried various combinations to see if we can move the candidate window
to a prefined position. (say x=100, y=200) and checked the position of 
the candidate window by calling ImmGetCandidateWindow() after setting it.

All the test cases we performed, it exhibited SUCCESS and returned the
predefined position despite the fact the Candidate window _is_ always on
the upper-left coner (except in case 2 where it rendered at the center of
the screen)

Test cases involves:
1) WM_IME_NOTIFY, WM_IME_CONTROL and IMC_SETCANDIDATEPOS
2) removing WM_IME_COMPOSITION, WM_IME_ENDCOMPOSITION
3) create Caret, remove Caret
4) MoveWindow(ImmGetDefaultIMEWnd(hWnd));
5) check the position on WM_PAINT

Need help!
(Reporter)

Comment 6

16 years ago
roy: from who, and what type of help do you need?
(Assignee)

Comment 7

16 years ago
>roy: from who, and what type of help do you need?
from mozilla community and if one can make the attached sample
works with MS PinYin :)
Status: NEW → ASSIGNED
(Assignee)

Comment 8

16 years ago
Created attachment 100458 [details] [diff] [review]
remove USE_OVERTHESPOT_IME() and replace it with PINYIN_IME_ON_XP()

gPinYinIMECaretCreated is defined to keep track of Caret Creation
and to avoid the resource leak.

Caret is created on nsWindow::HandleStartComposition()
and destroyed on nsWindow::HandleEndComposition()

shanjian: can you review?
Attachment #100343 - Attachment is obsolete: true
(Assignee)

Comment 9

16 years ago
Created attachment 100460 [details] [diff] [review]
oops, wrong attachment
Attachment #100458 - Attachment is obsolete: true

Comment 10

16 years ago
Comment on attachment 100460 [details] [diff] [review]
oops, wrong attachment

The code looks fine to me. r=shanjian

Comment 11

16 years ago
Comment on attachment 100460 [details] [diff] [review]
oops, wrong attachment

mark r= for shanjian he forgot to do that.,
Attachment #100460 - Flags: review+
Comment on attachment 100460 [details] [diff] [review]
oops, wrong attachment

sr=jst
Attachment #100460 - Flags: superreview+
(Assignee)

Comment 13

16 years ago
code checked into the trunk. 
Thanks shanjian and jst
(Reporter)

Comment 14

16 years ago
This is needed by a major embedding customer on 1.0 branch asap. 

Benefit: Provides support for PinYin IME Inline support on Windows XP. This
would benefit all customers of the 1.0 branch [embedding customer(s), Mozilla
and Netscape users].

Risk: Minimal -- Would only effect IME on Windows XP. Not other parts of the
code are touched.

Pls provide adt and Drivers' approval, so that we can have this checked in tonight.
Keywords: adt1.0.2, approval
Whiteboard: [adt2] [ETA Needed] → [adt2] [ETA 09/23]
(Reporter)

Comment 15

16 years ago
Comment on attachment 100460 [details] [diff] [review]
oops, wrong attachment

a=chofmann (verbal approval by phone) for checkin into the 1.0 branch. pls
check this into the 1.0 branch asap, then replace "mozilla1.0.2+" with 
"fixed1.0.2". thanks!
Attachment #100460 - Flags: approval+
(Reporter)

Updated

16 years ago
Keywords: mozilla1.0.2 → mozilla1.0.2+

Comment 16

16 years ago
be more presices about the risk
1. it won't impact linux or mac
2. it won't impact win 95,98,,me
3. it will only impact asian input method. so it won't impact any users who do
not use Asian input method
4. it won't impact Japanese, Korean or Traditional Chinese input method 
5. it only change the behavior of ONE particular input method in Chinese (there
are multiple chinese input method and this patch only affect ONE of them)

Comment 17

16 years ago
I think we should take this one. if dan or another adt member agree, then we
should + it. 

Comment 18

16 years ago
all the code in that pach are in the block which related to ime operation. For
normal keyboard input, it won't hit those code at all. 

Comment 19

16 years ago
here are some question I asked roy over the aim:
yungfongta (8:47:13 PM):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/carets/caretreference/caretfunctions/destroycaret.asp
yungfongta (8:47:38 PM):

DestroyCaret destroys the caret only if a window in the current task owns the
caret. If a window that is not in the current task owns the caret, DestroyCaret
does nothing and returns FALSE.

The system provides one caret per queue. A window should create a caret only
when it has the keyboard focus or is active. The window should destroy the caret
before losing the keyboard focus or becoming inactive.

For an example, see Destroying a Caret

yungfongta (8:47:49 PM): A window should create a caret only when it has the
keyboard focus or is active. The window should destroy the caret before losing
the keyboard focus or becoming inactive.
yungfongta (8:47:56 PM): does your patch handle that ?
yungfongta (8:48:12 PM): destroy the caret before losing the keyboard focus or
becoming inactive.
ROYYOKOYAMA (8:48:53 PM): yes, it was the same question shanjian asked me before
review it. we recei
ROYYOKOYAMA (8:49:17 PM): we receive EndComposition() when we become out of focus
yungfongta (8:52:23 PM): ok, it make sense. I guess that also cover the case
when we switch keyboard layout
ROYYOKOYAMA (8:52:49 PM): yes, it should send EndComposition() too


according to this conversion, I believe the DestroyCaret call have no problem 

Comment 20

16 years ago
Some comments explaining that these changes are workarounds for bugs in the
MS Pinyin IME on XP would help others understand this code later.

Comment 21

16 years ago
> Some comments explaining that these changes are workarounds for bugs in the
> MS Pinyin IME on XP would help others understand this code later.
more clarity:
Some comments explaining that these changes are "workarounds for bugs inline
style support in the MS Pinyin IME on XP" would help others understand this
code later.

Comment 22

16 years ago
The first place it call SetCaretPos is in HandleTextEvent and the 2nd place it
call SetCaret is in HandleCompositionStart . And HandleCompositionStart is
guarantee be called before any HandleTextEvent. That is why the first block it
does not try to create the caret. It don't need to since the 2nd block will do
it for it before it been called. 
The 2nd block do not need to worry about gPinYinIMECaretCreated is true already
because the only time HandleCompositionStart been called is after
HandleCompositionEnd been called, and in HandleCompositionEnd  we always destroy
the caret and turn gPinYinIMECaretCreated  to false.

If this is checked into the trunk shouldn't it be resolved FIXED?

Looks isolated enough to me, adt+
Keywords: adt1.0.2 → adt1.0.2+
(Assignee)

Comment 24

16 years ago
marking as fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 25

16 years ago
land the fix into trunk after approval. 
Keywords: mozilla1.0.2+ → fixed1.0.2

Comment 26

16 years ago
sorry, it should be
land the fix into branch for roy after approval. 

Comment 27

16 years ago
Is this a WinXP only problem? I use MS PinYin v3 IME on Windows 2000, the 
candidate window is always located in the top-left corner of the screen.
(Reporter)

Comment 28

16 years ago
ruixu: can you pls verify this as fixed on the today's trunk builds? thanks!
(Assignee)

Comment 29

16 years ago
>I use MS PinYin v3 IME on Windows 2000
rui: can you try on Win2k as well?  I was under impression that it was only for XP.
(Reporter)

Comment 30

16 years ago
ruixu: doh! forgot ... can you pls verify this as fixed on the today's 1.0
branch builds, as well (i.e. First Priority)? thanks!

Comment 31

16 years ago
It is not reproducible with 2002-09-08 branch build on SC WinXP, EN WinXP, JA 
WinXP, JA Win2K, SC WinNT4 and SC Win98SE, and no regression was found.
The candidate window is in correct position as well.
Keywords: fixed1.0.2 → verified1.0.2

Comment 32

16 years ago
Correction: build number in Comment #31 should be 2002-09-25-08 branch.

Comment 33

16 years ago
Hi Kyle,
I tested MS PinYin IME v3 on Simplified Chinese Win2000, and don't see the problem as mentioned in Comment #27. The default MS PinYin IME installed with Win2000 is v2, and I updated it to v3 with Simplified Chinese Office XP.

Could you please let me know which language version is your Windows 2000? How did you update to MS PinYin IME v3? Is it a standalone version or coming from Office XP? If it's a standalone version, where to get it? If it's from Office XP, which language version is your Office XP? Thanks.

Comment 34

16 years ago
Created attachment 100704 [details]
screen shot

I've updated and built my local tree today, and it still doesn't work well with
my MS PinYin 3.0. I think my MS PinYin IME does come with my OfficeXP + Chinese
Language Package. It's version is 3.0 2516, MS Word's version is 10.2627.2625.

And my language bar doesn't work well with mozilla either. I attached a zip
file that is consist of 3 screen shot gif files which can show how they look
like on my Windows2k.

Updated

16 years ago
Attachment #100704 - Attachment mime type: application/octet-stream → application/zip

Comment 35

16 years ago
Commericial branch WFM on US W2K in US region:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20020925
Netscape/7.0 

I tried MS Pinyin in Composer, URL bar and in an HTML form, and candidate
window appeared where the cursor was in the editable area.

Comment 36

16 years ago
Verified fixed with trunk 2002-09-26-08.

The problem for the candidate window position of MS PinYin IME v3 in Comment 
#27 is confirmed, and filed bug 171065.
Status: RESOLVED → VERIFIED
Keywords: inputmethod
You need to log in before you can comment on or make changes to this bug.