User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0 Build ID: 20170518000419 Steps to reproduce: 0. Windows XP, 7, 10, + 32bit FF or 64 bit FF (confirmed) beyond version 49 (estimation) 1. download a latest keyboard layout '3338-Saenaru-1.1.2-RC3.exe' in http://kldp.net/saenaru/release/ 2. install that keyboard with the option '새나루 콜맥(Colemak)' checked. 3. registry change [HKEY_CURRENT_USER\Software\OpenHangulProject\Saenaru] "ScanCodeBased"=dword:00000001 (from 00000000) 4. add keyboard at Control Panel - Region and Language - Keyboards and other input languages - Change keyboards... - Add -Korean - 한글입력기 (새나루 콜맥) 5. Use alt key to switch layout English to Korean 6. Use that keyboard layout to type some characters 1 = Shift + N (based on Colemak layout) = (J keycap) ( = [ (based on Colemak layout) = ("[" keycap) Actual results: Any other windows applications, any typing input was normal. However, Firefox ignores typing mentioned above. Other confirmed input contain contains all numbers and some symbols. I cannot say all symbols, for example the input ')' by pressing '-' is accepted but the input ')' by pressing [ is ignored. Here is layout for 세벌식+Qwerty https://upload.wikimedia.org/wikipedia/ko/thumb/9/9d/Sebul_keyboard_layout.svg/1280px-Sebul_keyboard_layout.svg.png The picture above is not exactly same with the layout mentioned here. Difference is English layout (greyed characters), but there was no problem with English layout. Expected results: Firefox should accept any typing as other windows applications does. I would not suspect Firefox if this problem was reproduced in other applications.
Summary: Firefox ignore Korean typing input partially in a certain logical keyboard layout → Firefox ignores typing input partially in a certain logical keyboard layout
Component: Untriaged → Internationalization
Product: Firefox → Core
This sounds kinda bad, although I have no idea how popular this keyboard is. Masayuki, any feeling on priority here?
I think that it's rare. If the keyboard layout sends correct WM_CHAR messages to applications, I have no idea why such bug could happen since I rewrote the keyboard message handling code to use WM_CHAR messages during the cycle of 52. Reporter: Did you reproduce the bug Firefox 51 or before? And if you'd attach log file of our keyboard message handling, I could fix it soon. If you have much time to log the behavior, please do: 1. Input "about:networking" to the URL bar and hit "Enter" key. 2. Press OK button in the page explaining the risk of "about:networking". 3. Click "Logging" in the left pane. 4. Write a path to log file in "Current Log File:" and click "Set Log File". 5. Write "sync,NativeKeyWidgets:5" in "Current Log Modules:" and click "Set Log Modules". 6. Click "Start Logging". (now, your any input is logging into the file, please do not type anything your privacy, like password) 7. Move focus to the search bar or something input field by mouse. 8. Press "Shift+J" (in QWERTY, Shift+N in Colemak, so, type "1") 9. Press "[" (in QWERTY, so, type "(") 10. Go back to "about:networking" tab and click "Stop Logging". 11. Attach the log file to this bug (from "Attach File" link in this page). The file name is "<you specified name>-main.<process number>".
Flags: needinfo?(masayuki) → needinfo?(key1)
I'd like to say thanks all of you who concerned the problem I submitted. Especially, Kohei Yoshino, Makoto Kato, Jim Mathies, Masayuki Nakano. I really appreciate you. Regarding Nakano's suggestion, I tried to produce the keyboard message handling log. However,the issue completely disappeared after updating Firefox from 53.0.3 to 54.0. Update to 54 as bug-killing trigger was confirmed on other computers of mine. If available, please leave some explanations about 'what was changed during update to 54 about this issue'. I've checked "What's new" page for version 54 at https://www.mozilla.org/en-US/firefox/54.0/releasenotes, but I couldn't find any relevant information with this issue. Thank you again.
(In reply to email@example.com from comment #3) > the issue completely disappeared after updating Firefox from 53.0.3 > to 54.0. marking WFM per that comment. Please reopen if the bug exists in latest Nightly builds.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.