Can not get the correctly single byte non-ascii characters on CJK IME(keyboard layout)

RESOLVED FIXED in mozilla1.2beta

Status

()

P4
major
RESOLVED FIXED
18 years ago
9 years ago

People

(Reporter: amyy, Assigned: tetsuroy)

Tracking

({inputmethod, intl, relnote})

Trunk
mozilla1.2beta
x86
Windows 2000
inputmethod, intl, relnote
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
Build: N6.1 & 08-10 trunk build on Window2000-CN and WinME-Ja

Steps to repro:
1. Launch browser.
2. I have global CJK IME on Win2k-CN and Japanese IME on WinME-Ja.
3. Turn on CJK IME (keyboard), try to type some non-ascii characters.
   e.g. some accent characters - Alt-225 ...etc.

Result:
You will either can not get any input in Browser or Composer, or get one without
accent.

IE5.5 will get the correct characters though.
(Reporter)

Updated

18 years ago
Keywords: intl
QA Contact: andreasb → ylong

Updated

18 years ago
Keywords: nsBranch

Comment 1

18 years ago
can you be explicit which key sequence you typed? and what you expect to be
generated? 

Comment 2

18 years ago
set to m9.5
Target Milestone: --- → mozilla0.9.5

Comment 3

18 years ago
ylong - please provide us with more details. Thanks.
(Reporter)

Comment 4

18 years ago
Here is one example about it:

On netscape home page, if I press "Alt-225" in URL location bar or search text 
field, I expect will get a non-acii character "ив" (a with accent).

Actually result by repeat the steps above:
1. Win2000 traditional Chinese / default MS Traditonal Chinese IME(keyboard):
08-27 trunk build - got letter "a" (without accent)
IE - got non-ascii character "ив" (with accent)

2. Win2000 simplified Chinese / default MS Simplified Chinese IME(keyboard):
08-27 trunk build - no any letter appears
IE - got non-ascii character "ив" (with accent)
 
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Reporter)

Updated

17 years ago
Summary: Can not get the correctly single byte non-ascii characters on CJK IME(keyboard) → Can not get the correctly single byte non-ascii characters on CJK IME(keyboard layout)
(Reporter)

Comment 5

17 years ago
Same problem also on WinXP-Ja, and also as I said before on WinME-Ja.

Comment 6

17 years ago
Removing myself and adding Todd.
(Reporter)

Comment 7

17 years ago
Change severity to major.
Severity: normal → major

Comment 8

17 years ago
nsbranch- since Frank moved it to 0.9.5
Keywords: nsbranch → nsbranch-
(Reporter)

Comment 9

17 years ago
This problem is happens on both:
1. CJK MS IME on CJK system.
2. CJK input with CJK keyboard layout - can be added by control panel.

We have another bug 98376 which is talking about one very specific case - Ja
input with US keyboard.  I believe the fix of this bug will fix bug 98376, and
better to fix this one first. however bug 98376 still has "nsbranch" keyword,
and this is "nsbranch-" and moved to 0.9.5.

I think this one should has high priority than bug 98376.
(Assignee)

Comment 10

17 years ago
setting the priority
Priority: -- → P1
(Assignee)

Comment 11

17 years ago
Platform SDK/winuser.h has new msg. 

#if(_WIN32_WINNT >= 0x0501)
#define WM_UNICHAR                      0x0109
#define WM_KEYLAST                      0x0109
#define UNICODE_NOCHAR                  0xFFFF
#else
#define WM_KEYLAST                      0x0108
#endif /* _WIN32_WINNT >= 0x0501 */

Comment 12

17 years ago
Are these messages used only by NT.
This is being reported on both Window2000-CN and WinME-Ja.
I thought ME is 9x based not NT based.

(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6
(Assignee)

Comment 13

17 years ago
*** Bug 103231 has been marked as a duplicate of this bug. ***

Comment 14

17 years ago
what will happen in Notepad or Word?
(Assignee)

Comment 15

17 years ago
NotePad:
Keyboard             <Alt>+169                       <Alt>+0169
--------------   ---------------------  -----------------------
Ja-IME                'Ž©' = half with 'u'               'Ž©' = half with 'u'
En                       'Ž©' = half with 'u'               'Ž©' = copy right symbol


(Assignee)

Comment 16

17 years ago
I set breakpoints on WM_UNICHAR, WM_DEADCHAR, WM_IME_CHAR, WM_CHAR
Only WM_CHAR is called with <Alt>+0169 and <Alt>+169.
I guess WM_UNICHAR is only supported in WinXP.  The msg is not gets called in W2K-ja.

Anybody have suggestions?  I am at a point where we need to compile mozilla as an Unicode app
in order to fix this issue.

Note: how to create unicode app
1. Add _UNICODE and UNICODE preprocesser definition under C/C++/General
2. Delete _MBCS preprocesser definition under C/C++/General
3. Choose the __stdcall or __fastcall calling convention under C/C++/Code Generation
4. Set Entry Point Symbol to wWinMainCRTStartup under Link  (MFC app only)

Comment 17

17 years ago
> Anybody have suggestions?  I am at a point where we need to compile mozilla as
> an Unicode app in order to fix this issue.

How will this work on Win9x and ME?
(Assignee)

Comment 18

17 years ago
bobj: MS have a lib called "Microsoft Layer for Unicode on Windows 95/98/Me Systems
"
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win32/unilayer_4wj7.asp

Basically, it's a library you can link to your Unicode App.  

Comment 19

17 years ago
I think this should be P4 bug instead of P1. How many user will use this feature
? I think most of real user will either switch to a different keyboard layout to
type the text or copy and paste from ucharmap. 
Priority: P1 → P4

Comment 20

17 years ago
I think this one should be P4 future. 
Any documentation mention such feature in Window IME?
Target Milestone: mozilla0.9.6 → Future

Updated

17 years ago
Blocks: 107067

Updated

17 years ago
Keywords: nsbranch-

Updated

17 years ago
No longer blocks: 107067
Keywords: relnote
(Assignee)

Updated

17 years ago
Target Milestone: Future → mozilla1.2beta

Comment 21

17 years ago
*** Bug 155688 has been marked as a duplicate of this bug. ***

Comment 22

17 years ago
Update info:

Retested on branch build 2002-07-03-08-1.0
1. on NT based OS: some high ascii characters can not be entered correctly.
2. on Win9x: when entering at 2nd time, sometimes a Chinese character will be 
shown up.
please refer to the attachment.

Comment 23

17 years ago
Created attachment 90151 [details]
the results from branch build 2002-07-03-08-1.0

Comment 24

17 years ago
Which keys did you enter?  with or without the leading zeros?

More info on the leading zero from W2K help system for
"key sequences - inputting  characters not on the keyboard":

   ...
   Windows 2000 generates the character you specified and passes it
   to the foreground program.

 Notes

  - If the first digit you type is 0, the value is recognized as a code
  point, or character value, in the current input locale. For example,
  when your current input locale is US-English (Code page 1252: Windows
  Latin-1), pressing the ALT key and then typing 0163 on the numeric
  keypad produces £, the pound sign (U+00A3). When your current input
  locale is   Russia (Code page 1251: Windows Cyrillic), the same key
  sequence produces the Cyrillic capital letter JE (U+0408). 

  - If the first digit you type is any number from 1 through 9, the value
  is recognized as a code point in the system's OEM code page. The result
  differs depending on the Windows system locale specified in Regional
  Options in Control Panel. For example, if your system locale is English
  (US), the code page is 437 (MS-DOS Latin US), so pressing the ALT key
  and then typing 163 on the numeric keypad produces ú (U+00FA, Latin
  small letter U with acute). If your system locale is Greek (OEM code
  page 737 MS-DOS Greek), the same sequence produces the Greek small
  letter MU (U+03BC). 

Comment 25

17 years ago
>> Which keys did you enter?  with or without the leading zeros?
The keys entered start from 230, and without the leading zeros.
(Assignee)

Comment 26

16 years ago
I just checked in the code for making mozilla Unicode app.
Here is what I have/did:
 1) Windows XP- CS with English-US system locale w/ En keyboard locale
   Mozilla :
     - enter "Alt-163" in text field, got letter "u" (with acute)
     - enter "Alt-0163" in text field, got letter "pound sign"
   IE :
     - enter "Alt-163" in text field, got letter "u" (with acute)
     - enter "Alt-0163" in text field, got letter "pound sign"
 2) Windows XP- CS with English-US system locale w/ Ja keyboard locale
   Mozilla :
     - enter "Alt-163" in text field, got letter "u" (with acute)
     - enter "Alt-0163" in text field, got "1/2 width right corner bracket"
   IE :
     - enter "Alt-163" in text field, got symbol "heart"
     - enter "Alt-0163" in text field, got symbol "heart"

It looks like mozilla is respecting the current keyboard input locale; but 
IE is not.  Are we better than IE? (sure!)

ylong: can you try it in Win9x system?
(Assignee)

Comment 27

16 years ago
ylong: unicode version patch is rolled back last night. :(
       I have a patch to fix the problem.  Moz Unicode should be ready tomorrow
       Please postpone this test until tomorrow.  Thanks
(Reporter)

Comment 28

16 years ago
Here are some results on 09-24 trunk build:

1. Win98-EN: Mozilla/Netscape & IE (Same result):

English IME:
Alt-163: u with umlaut.
Alt-0163: pound sign, "&#163;".

Japanese IME:
Alt-163: a Kanji character
Alt-0163:  "1/2 width right corner bracket", "&#65379;".

2. WinME-JA: Mozilla/Netscape & IE (Same result):

English IME:
Alt-163 & Alt-0163: pound sign, "&#163;".

Japanese IME:
Alt-163 & Alt-0163: "1/2 width right corner bracket", "&#65379;".

So, seems on Win9x system, the results are same between IE and mozilla in this case.
(Assignee)

Comment 29

16 years ago
I believe this bug is fixed with Unicode build. 
I am going to mark this as fix and making it as depends on 104934   
Please verify once 104934 gets fixed. (I will be today or tomorrow)
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Depends on: 104934
Resolution: --- → FIXED
(Reporter)

Comment 30

16 years ago
Change QA contact to Carine.

Carine, could you please verify this?
Since Roy just checked in bug 104934 today, so it will affect after tomorrow's
trunk build.  Please test on all windows platforms.
QA Contact: ylong → carineh00
Keywords: inputmethod
You need to log in before you can comment on or make changes to this bug.