Open Bug 865564 Opened 11 years ago Updated 2 years ago

[UIEvents-key] Map Hangul related keys to KeyboardEvent.key value on Linux

Categories

(Core :: DOM: Events, defect, P3)

x86_64
Linux
defect

Tracking

()

People

(Reporter: masayuki, Unassigned)

References

Details

(Keywords: inputmethod, intl)

At the initial implementation of D3E KeyboardEvent.key, following Hangul related keys are mapped to "Unidentified". They should be mapped correctly as far as possible (I don't familiar with Korean language, though).

GDK_Hangul
GDK_Hangul_Start
GDK_Hangul_End
GDK_Hangul_Hanja
GDK_Hangul_Jamo
GDK_Hangul_Romaja
GDK_Hangul_Jeonja
GDK_Hangul_Banja
GDK_Hangul_PreHanja
GDK_Hangul_PostHanja
Summary: Map Hangul related keys to D3E's key value list → Map Hangul related keys to D3E's key value
I'm not familiar with Hangul IME, so, I'm not sure the actual meaning of the keysyms.

With Korean keyboard, I can see only two additional keys which cause only GDK_Hangul and GDK_Hangul_Hanja with any modifier state.

However, I found this document, see Figure 8:
http://www.cs.columbia.edu/~lennox/draft-lennox-avt-app-sharing-00.html#anchor3

Name                       Code    Note
----                       ----    ----
Hangul                     0x31    Hangul start/stop(toggle) 
Hangul Start               0x32    Hangul start 
Hangul End                 0x33    Hangul end, English start 
Hangul Hanja               0x34    Start Hangul->Hanja Conversion 
Hangul Jamo                0x35    Hangul Jamo mode 
Hangul Romaja              0x36    Hangul Romaja mode 
Hangul Code Input          0x37    Hangul code input mode 
Hangul Jeonja              0x38    Jeonja mode 
Hangul Banja               0x39    Banja mode 
Hangul Pre-Hanja           0x3A    Pre Hanja conversion 
Hangul Post-Hanja          0x3B    Post Hanja conversion 
Hangul Single Candidate    0x3C    Single candidate 
Hangul Multiple Candidate  0x3D    Multiple candidate 
Hangul Previous Candidate  0x3E    Previous candidate 
Hangul Special             0x3F    Special symbols 

I'll map the keysyms as far as possible with this hint.
I searched about "Jamo", "Romaja", "Jeonja", "Banja" and "Junja".

According to this topic of wikipedia
http://en.wikipedia.org/wiki/Korean_romanization

GDK_Romaja should be mapped to "Alphanumeric" rather than "RomanCharacters".

However, I don't find the meaning of other words.

channy: Could you explain about the meaning of above words?

We need to map the keysyms in comment #0 to the keynames which are defined by DOM Level 3 Events (only if proper keyname is defined for a keysym)
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#key-values-list

I'm thinking about the mapping is:

GDK_Hangul                    "HangulMode"
GDK_Hangul_Start              "HangulMode"
GDK_Hangul_End                "Alphanumeric"
GDK_Hangul_Hanja              "HanjaMode"              
GDK_Hangul_Jamo               (not sure)
GDK_Hangul_Romaja             "Alphanumeric"
GDK_Hangul_Jeonja             (not sure)
GDK_Hangul_Banja              (not sure)
GDK_Hangul_PreHanja           "PreviousCandidate"
GDK_Hangul_PostHanja          "NextCandidate"

Note that the left key of space key causes GDK_Hangul. The right key of space key causes GDK_Hangul_Hanja. I've not found the keys which cause other keysyms on the standard Korean keyboard.

Other possible DOM Level 3 Events defined keynames are:

'FinalMode: The Final Mode (Final) key used on some Asian keyboards, to enable the final mode for IMEs.
'RomanCharacters': The Roman Characters function key, also known as the 'Youngja' or 'Young' key.
'JunjaMode': The Junja (Korean characters) Mode key.
Flags: needinfo?(channy)
I changed to get help from Jungshik.
Flags: needinfo?(channy) → needinfo?(jshin1987)
I found this document:
http://msdn.microsoft.com/en-us/library/cc194846.aspx

Junja mode means "Single-byte Latin letters" mode.

Banja mode means "Double byte Latin letters" mode.

Then, it seems that GDK_Hangul_End and GDK_Hangul_Romaja should be mapped to "JunjaMode".
channy:

We've not gotten the reply from Jungshik, and my question isn't technical question. I just want to know the equivalent between GDK keysyms and D3E key names of Korean IME input modes. Don't you have no advice for me?

I'm thinking current mapping should be:

GDK_Hangul                    "HangulMode"
GDK_Hangul_Start              "HangulMode"
GDK_Hangul_End                "JunjaMode"
GDK_Hangul_Hanja              "HanjaMode"              
GDK_Hangul_Jamo               (not sure)
GDK_Hangul_Romaja             "JunjaMode"
GDK_Hangul_Jeonja             (not sure)
GDK_Hangul_Banja              "Unidentified" (We should request to add new key name to W3C)
GDK_Hangul_PreHanja           "PreviousCandidate"
GDK_Hangul_PostHanja          "NextCandidate"
Flags: needinfo?(channy)
Er, perhaps, GDK_Hangul_Jamo should be HangulMode.
Flags: needinfo?(channy)
Summary: Map Hangul related keys to D3E's key value → [UIEvents-key] Map Hangul related keys to KeyboardEvent.key value

Moving all open keyboard/IME handling bugs to DOM: UI Events & Focus Handling component.

Component: Widget: Gtk → DOM: UI Events & Focus Handling

Kagami, when you have much time, could you investigate proper key values for the keysym values? You can know which key press causes which keysyms with logging KeymapWrapperWidgets:3,sync (see "Logging" in about:networking).

Component: DOM: UI Events & Focus Handling → DOM: Events
Flags: needinfo?(jshin1987) → needinfo?(krosylight)
Priority: -- → P3
Summary: [UIEvents-key] Map Hangul related keys to KeyboardEvent.key value → [UIEvents-key] Map Hangul related keys to KeyboardEvent.key value on Linux

I found this document:
http://msdn.microsoft.com/en-us/library/cc194846.aspx

Junja mode means "Single-byte Latin letters" mode.

Banja mode means "Double byte Latin letters" mode.

This is reversed. Junja(=Jeonja) should be fullwidth mode and thus double byte mode while Banja should be halfwidth mode and thus single byte mode. Not sure why the document described it in a wrong way. (Setting those mode doesn't switch Hangul mode to Romaja mode.)

You can know which key press causes which keysyms with logging KeymapWrapperWidgets:3,sync (see "Logging" in about:networking).

It doesn't seem to record anything, what should I do after setting log modules and start logging?

Flags: needinfo?(krosylight) → needinfo?(masayuki)

Ah okay, it's a Linux thing... Seems special keys doesn't work inside WSL, so I'll find some time to dual boot into Linux.

Flags: needinfo?(masayuki)
Flags: needinfo?(krosylight)

I installed Ubuntu on my old Surface 3 with Korean type cover and got some log:

[Parent 3182: Main Thread]: I/KeymapWrapperWidgets   HandleKeyPressEvent(), the event was handled by IMContextWrapper
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets 0x7fcd162d9c80 InitKeyEvent, modifierState=0x00000000 aKeyEvent={ mMessage=eKeyDown, isShift=FALSE, isControl=FALSE, isAlt=FALSE, isMeta=FALSE , mKeyCode=0xE5, mCharCode=NULL (0x0000), mKeyNameIndex=Process, mKeyValue="", mCodeNameIndex=Enter, mCodeValue="", mLocation=KEY_LOCATION_STANDARD, mIsRepeat=FALSE }
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets FilterEvents(aXEvent={ type=KeyRelease, xkey={ keycode=0x00000024, state=0x00002000, time=502770 } }, aGdkEvent={ state=0x00000000 }), detected key release
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets HandleKeyReleaseEvent(aWindow=0x7fcd1f129000, aGdkKeyEvent={ type=GDK_KEY_RELEASE, keyval=Return(0xFF0D), state=0x00002000, hardware_keycode=0x00000024, time=502770, is_modifier=FALSE })
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets   HandleKeyReleaseEvent(), the event was handled by IMContextWrapper
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets HandleKeyReleaseEvent(aWindow=0x7fcd1f129000, aGdkKeyEvent={ type=GDK_KEY_RELEASE, keyval=Return(0xFF0D), state=0x02002000, hardware_keycode=0x00000024, time=502770, is_modifier=FALSE })
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets 0x7fcd162d9c80 InitKeyEvent, modifierState=0x02002000 aKeyEvent={ mMessage=eKeyUp, isShift=FALSE, isControl=FALSE, isAlt=FALSE, isMeta=FALSE , mKeyCode=0x0D, mCharCode=NULL (0x0000), mKeyNameIndex=Enter, mKeyValue="", mCodeNameIndex=Enter, mCodeValue="", mLocation=KEY_LOCATION_STANDARD, mIsRepeat=FALSE }
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets   HandleKeyReleaseEvent(), dispatched eKeyUp event (isCancelled=FALSE)
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets HandleKeyPressEvent(aWindow=0x7fcd1f129000, aGdkKeyEvent={ type=GDK_KEY_PRESS, keyval=Alt_L(0xFFE9), state=0x00002000, hardware_keycode=0x00000040, time=505796, is_modifier=TRUE })
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets   HandleKeyPressEvent(), the event was handled by IMContextWrapper
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets HandleKeyPressEvent(aWindow=0x7fcd1f129000, aGdkKeyEvent={ type=GDK_KEY_PRESS, keyval=Alt_L(0xFFE9), state=0x02002000, hardware_keycode=0x00000040, time=505796, is_modifier=TRUE })
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets 0x7fcd162d9c80 InitKeyEvent, modifierState=0x02002000 aKeyEvent={ mMessage=eKeyDown, isShift=FALSE, isControl=FALSE, isAlt=FALSE, isMeta=FALSE , mKeyCode=0x12, mCharCode=NULL (0x0000), mKeyNameIndex=Alt, mKeyValue="", mCodeNameIndex=AltLeft, mCodeValue="", mLocation=KEY_LOCATION_LEFT, mIsRepeat=FALSE }
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets   HandleKeyPressEvent(), dispatched eKeyDown event and it wasn't consumed
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets 0x7fcd162d9c80 InitKeyEvent, modifierState=0x02002000 aKeyEvent={ mMessage=eKeyPress, isShift=FALSE, isControl=FALSE, isAlt=FALSE, isMeta=FALSE , mKeyCode=0x12, mCharCode=NULL (0x0000), mKeyNameIndex=Alt, mKeyValue="", mCodeNameIndex=AltLeft, mCodeValue="", mLocation=KEY_LOCATION_LEFT, mIsRepeat=FALSE }
[Parent 3182: Main Thread]: I/KeymapWrapperWidgets   HandleKeyPressEvent(), didn't dispatch eKeyPress event (status=nsEventStatus_eIgnore)

Is hardware_keycode numeric value what you need?

Flags: needinfo?(krosylight) → needinfo?(masayuki)

Resetting assignee which I don't work on in this several months.

Assignee: masayuki → nobody
Flags: needinfo?(masayuki)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.