Fallback onscreen keyboard unusable when non-QWERTY input method is active |
||||||||
Issue descriptionThe onscreen keyboard that's displayed when in tablet mode displays a QWERTY layout regardless of the active input method. If you have Dvorak selected, the keys are remapped to Dvorak (onscreen 's' produces 'o', 'd' produces 'e', and so on), but the onscreen keyboard lacks keys for ',' (needed for typing 'w' with Dvorak), '.' (needed to type 'v'), and '/' (needed to type 'z'). When an alternate input method is selected, we should probably show its keys in the proper locations on the onscreen keyboard. If that'll take a while to do, we should avoid remapping keys when showing the QWERTY layout until then, and just have it function as a regular QWERTY keyboard. The thing that we're doing right now makes the onscreen keyboard unusable (and confusing) for non-QWERTY users. Biao, are you the right owner for this?
,
Nov 2 2016
(Drive-by comment. I just accidentally saw this issue while searching for other unrelated bug... :)) The onscreen keyboard looks just working as desired on my environment (it shows Dvorak; find attached.) Either something else is going wrong, or more detailed repro steps may be useful.
,
Nov 2 2016
Yes, that looks correct -- thanks for the screenshot. I'll check my input settings when I'm in the office tomorrow to see if there are any clues about why I'm seeing something else. In case it's relevant, the keyboard that I saw was displayed when I tapped the omnibox after putting a kevin device into TouchUI by converting it to tablet mode.
,
Nov 2 2016
derat@, did you flash the official image on your kevin device? Or you compiled a local version of Chrome OS (or Chromium OS) by yourself?
,
Nov 2 2016
Btw, what I am guessing is that you might see the system fallback on-screen keyboard which only does basic typing without suggestions and stick to QWERTY layout. The easy way to identify whether you're seeing the system fallback on-screen keyboard is to check the label on the SPACE key. If it shows "English", then it is the system fallback one. If it shows "US Keyboard", then it is the correct/expected one.
,
Nov 2 2016
Good guess! This is my own build, and I'm using the system fallback (spacebar says "English"). So it sounds like should be low-priority since it doesn't affect end-users, right?
,
Nov 3 2016
Yes, this doesn't affect end-users.
,
Jan 24 2017
Unassigned, up for grabs by new VK team :)
,
Jan 25 2017
This seems to already be fixed according to comment #2 as it only happens on derat@'s own build. Marking as fixed.
,
Jan 25 2017
It's low-priority, but the fallback keyboard is presumably still doing this. Will this affect people doing their own builds? If so, I think it makes sense to keep the bug open until it's fixed and prioritize it accordingly.
,
Jan 25 2017
Feel free to leave it assigned to me for now. :-)
,
Sep 18
Archiving old bugs that have only received trivial updates for some time. If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!
,
Sep 18
,
Sep 19
This is still broken, but I'm tired of reopening the bug. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by abodenha@chromium.org
, Nov 1 2016Labels: -Pri-2 Pri-1
Owner: yhanada@chromium.org
Status: Assigned (was: Untriaged)