New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 46 users

Issue metadata

Status: Verified
Closed: Jun 2015
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Feature

Sign in to add a comment

Issue 167237: Need way to remap CapsLock key

Reported by, Dec 21 2012 Project Member

Issue description

OS: Chrome OS

The Chrome OS "Keyboard settings" dialog allows remapping the values of Search, Ctrl and Alt.  The new Acer C7 Chromebook has a Caps lock key, which is notably missing from the options for remapping.  This issue also arises when using an external keyboard.

Comment 1 by, Jan 2 2013

Labels: Feature-Settings

Comment 2 by, Jan 2 2013

Status: WontFix
What version are you running. We added being able to remap caps lock in M25. Re-open if you still see this in M25.

Comment 3 by, Jan 30 2013

Sorry for the slow response.  I just checked this again, and I still don't see the ability to remap caps lock.  See attached screenshot.  This is on a Samsung 550, with an external Dell 24" monitor attached via DisplayPort and a Microsoft Natural Ergonomic Keyboard 4000 v1.0 plugged in.
No CapsLock remapping on M25.png
108 KB View Download

Comment 4 by, Jan 30 2013

Status: Available

Comment 5 by, Jan 30 2013

+sheckylin (in Tango team who seems to be interested in refactoring Chrome input stack)

We don't show the drop-down for remapping caps lock on Lumpy (Samsung 550) because:
- Lumpy's system keyboard does not have Caps Lock.
- Detecting an external USB keyboard is relatively easy, but it's difficult to know whether the external keyboard has Caps Lock or not. Please note that we have several types of "Chrome" USB keyboard which don't have Caps Lock. Showing the UI for remapping Caps Lock when a Chrome USB keyboard is connected does not make sense.

I understand this is not optimal, but the run-time Caps Lock detection feature would require fair amount of groundwork.

Comment 6 by, Jan 30 2013

Owner: ----
Yes, showing a UI element when the hardware does not support it is not ideal, but the user is simply puzzled at the noop setting rather than frustrated.

However, hiding a UI element when the hardware supports it and the user needs it is incredibly frustrating.

My guess is that the majority of external keyboards plugged into Chromebooks are not Chrome keyboards.  If our goal is to minimize frustrating user experiences, I think we should show the capslock remapping UI when an external keyboard is attached.

The current behavior of hiding the capslock remapping is frustrating enough that I reach for my Mac instead of my Chromebook when telecommuting, which is sad.

Question: do we hide the caplock remapping at all times on Chromeboxes?  If I had a Chromebox, the first thing I'd do would be to plug in an ergonomic keyboard.  It would be maddening if the capslock remapping was hidden in that case.

Comment 7 Deleted

Comment 8 by, Jan 31 2013

FYI, we currently always show the capslock remapping option for Stumpy (the chromebox).

Comment 9 by, Mar 8 2013

[drive-by comment]

Another approach for this to unify the UI without keyboard detection magic would be to support remapping keys by having the user press the (modifier) key they want to remap then let them select the action.

Comment 10 by, Mar 10 2013

Project Member
Labels: -Area-UI -Feature-Ash -Feature-Settings Cr-UI-Settings Cr-UI-Shell Cr-UI

Comment 11 by, Mar 15 2013

It just dawned on me that the keyboard settings are in webui.  I just went on my chromebook, did Inspect Element, removed "hidden" from the HTML for the caps lock drop down, and changed the selection to Ctrl. The preference was saved (persists across reboots and is sync'd to other devices).  Unfortunately, it is still ignored on my chromebook.  It turns out that the same command line switch that controls whether the caps lock remapping dropdown is displayed is also consulted in chrome/browser/ui/ash/ during the actual key remapping.  So, even if the user has configured caps lock to be remapped, it is still ignored.

I understand not wanting to clutter up the UI with an option that may not be valid, but ignoring an already-set preference seems unnecessary.  Why allow the user to remap caps lock on their chromebox, then sync that pref to their Pixel, only to ignore it when they plug the same keyboard in?

I'll happily send out a CL for review that removes the HasChromeOSKeyboard() check from, but I'd like to first confirm on this bug that people think the modification is okay.

Getting this into R27 so I can use my chromebook for telecommuting would make me very, very happy!

Comment 12 by, Mar 21 2013

re #11:
I'd defer to Alex, but I think removing the HasChromeOSKeyboard() check from would break some use cases. For example, what do you think about the following scenario?

1. The user borrows someone's Chromebox. Signs in to the machine, remaps Caps Lock to Ctrl.
2. (Days later) The user signs in to his/her Pixel. Attach an external USB keyboard. Press Caps Lock.

At this point, if we implement your proposal, Caps Lock works as Ctrl. This might or might not be okay for the user, but the point is that the user has no way(*) to reset the mapping anymore since the user does not have access to a Chromebox. My feeling is that we should implement either keyboard type detection or #9.

(*) except using "Inspect Element" to remove the "hidden" attribute from the element.

Comment 13 by, Mar 21 2013

I guess we have a different definition of "break".  :-)  The example you gave in #12 as to why the rewriter check shouldn't be removed is identical to the example I gave in #11 as to why it *should* be removed, with the only difference being our assumption about the user's expectation.  I'd argue that if the user chose to remap capslock with an external keyboard on one device, that they want that same behavior on other devices.  Arbitrarily ignoring their preference on some devices and not others is frustrating.

How about this as a solution that will allow power users to remap the caps lock on a Pixel, while keeping the current behavior for other users:
- change this pref to not be sync'd.  If we're ignoring it anyway on some devices, I think it begs the question about whether it should be sync'd at all.
- remove the HasChromeOsKeyboard check in, so that whatever pref is set by the user locally is respected.

This will maintain the current behavior: users of chromebooks don't have UI to remap capslock, and external keyboards have a functioning capslock by default.  But, a power user can force a change to the pref value if they feel strongly about it (via Inspect Element on the keyboard prefs dialog).

I agree that in the long term we should do full keyboard type detection or #9, but in the short term can we implement my proposal?  I have many years worth of muscle memory that says that CapsLock==Ctrl when writing code, and the lack of some way to remap capslock literally means that I can't telecommute on my Pixel, and I need to use another device that allows remapping.  I doubt I'm the only developer who considers capslock remapping a "must have" feature for their keyboard when doing development.

Comment 14 by, Mar 21 2013

#13 SGTM as a short-term solution, although "this will maintain the current behavior" is not exactly true. A user who have two Chromeboxes (or two Acer $199 Chromebooks, or one Chromebox and one Acer) has to set up his/her machine one by one.

I'll review your CL if Alex (Kuscher@) is happy with #13.

Comment 15 by, Mar 21 2013

+derat FYI

Comment 16 by, Mar 22 2013

Labels: -Cr-UI Review-UI
We should do this right. Which means the pref should be available for keyboards that have Caps Lock and not available when they don't. 

While we work on that I am receptive to changing the default to enable the caps lock setting on all external keyboards. It is incredibly likely that those have a caps lock key so we are currently erring on the wrong side. 

Adding UI leads since I know any keyboard remapping is hugely controversial.

Comment 17 by, Mar 22 2013

The change proposed in #16 sounds great, but it will still require the change I propose in #13, or the newly-exposed UI settings will be ignored by the event rewriter.  So, it sounds like this sequence of changes need to be made:

- [proposal from #13] remove the HasChromeOsKeyboard check in, so that whatever pref is set by the user locally is respected (I have this out for review in
- [proposal from #16] enable the caps lock setting on all external keyboards
- [long-term goal] full external keyboard detection (hide capslock remapping options only if external keyboard is missing the capslock key)

If we land the #13 change now, then power users will at least have options while we wait for #16 to make this more broadly accessible.

Comment 18 by, Mar 28 2013

Why do you hate your users? Look what you made me do to make Caps=>Ctrl mapping on a Pixel!

(Just kidding. Great to see you guys are looking at this -- I was a bit confused because I think I saw at least two different bugs asking for exactly this feature closed as wontfix.)
245 KB View Download

Comment 19 by, Apr 2 2013

on the french keyboard I have numbers 1-9 "shifted". Since there is no numeric pad It could be interesting to have the CAPS LOCK switch to NUM LOCK..


Comment 20 by, Apr 15 2013

Until this bug is fixed, is there any way to re-map caps lock to ctrl?  I've got my Pixel in developer mode, so I have full root access via the shell...

Really hoping there is a way to do this as I am working remotely for the next 3.5 weeks on my Pixel and really need to have caps lock remapped to ctrl on an external keyboard to avoid exacerbating painful RSI in my left wrist.  Thanks!

Comment 21 by, May 6 2013

Labels: -Review-UI M-29
Status: Assigned
[Triage] Review-UI says go with changes proposed in #17.  Apologies for the delay.  

Harry, over to you. Basically, we want always show the caps lock keyboard mapping pref any time an external keyboard is available. You'll need to dig into the various values for HasChromeOsKeyboard.

davidroche - I can OWNERS-approve the ash/ directories for your patch but I can't see the diffs, can you rebase and reupload?

Comment 22 by, May 6 2013

@jamescook: rebased and uploaded new patchset

Comment 23 by, May 6 2013

Looks like this may be interesting for me.

Comment 24 by, May 8 2013

Project Member
r198999 | | 2013-05-08T21:12:19.962414Z

Changed paths:

Change CapsLock remapping pref to not be syncable, so each device can have
its own value.  Update EventRewriter to honor local CapsLock pref setting,
even if the UI doesn't show CapsLock in keyboard dialog.

BUG= 167237 

Review URL:

Comment 25 by, May 14 2013

Incidentally (not that anybody will care):

The Search key is reported as Left Meta by the kernel (and/or the Embedded Controller), which is also used by the Left Windows key.  So remapping Search also remaps that key in any external keyboard.

Comment 26 by, May 14 2013

Is it really that bad to always show a Caps Lock drop-down?

If users are going to be confused because they can't find the Caps Lock key on their Chromebook, there may be acceptable UI solutions to reduce the confusion.  For instance:

Keyboard Settings
Search  | Search |
Ctrl    |  Ctrl  |
Alt     |  Alt   |
CapsLock|CapsLock| (External KBD Only)

The Keyboard Settings window looks pitifully small anyway.  This would be an excuse to fatten it a bit.

Also, it seems unfriendly to require attaching an external keyboard before one can change its setting.

Feel free to totally rebuff me if this has already been decided.

Comment 27 by, May 20 2013

We discussed this before. Showing it always will just be confusing as most Chrome OS devices won't even have a Caps Lock key. Showing text and explaining a setting is not as elegant.

Assigning back to Harry if this is right.

Comment 28 by, Jun 10 2013

Labels: -M-29 M-30

Comment 29 by, Aug 6 2013

Will the remapping of caplocks to control shows up for HP and Acer chromebook ?  Those chomebooks have the capslock key where the control key should be on the device.

Comment 30 by, Aug 9 2013

Labels: -M-30 M-31

Comment 31 by, Sep 26 2013

Labels: -M-31 M-32 MovedFrom-31
Moving all non essential bugs to the next Milestone.

Comment 32 by, Nov 8 2013

Labels: -M-32 MovedFrom-32
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.

Comment 33 by, Nov 8 2013

Kuscher@, since we have Docked mode, could we at least expose it in those cases? I agree with semenzato@ that this would be fine all the time, but as a non-UX person, at least making it accessible in Docked mode would be a huge improvement.

Comment 34 Deleted

Comment 35 by, Nov 8 2013

"Docked mode" really only refers to some code in the power manager to avoid going to sleep when the lid is closed while an external display is connected. I don't think that conditionally displaying a keyboard setting based on whether a monitor is connected or not makes sense.

Harry, how far away is the change to show the setting only if an external keyboard is connected? If it's not happening soon, I don't see much harm in always displaying the setting until we're able to conditionally show it.

Along the lines of #26, what about if the label says "Caps Lock" when HasChromeOsKeyboard() is false and "Caps Lock (external keyboards)" when it's true? I agree that it's less elegant than showing the setting conditionally but feel that it's better than not showing the setting when the user actually wants to change it.

Comment 36 by, Dec 12 2013

Labels: -Pri-2 Pri-3
This is P2 but has no milestone assigned, so it's not getting the attention it deserves.

I'm bumping such bugs down to P3. It's likely that this is incorrect for some of them.

If this bug should be handled as something other than P3 please bump it back up and CC me so I can review and get it scheduled in a appropriate milestone.

Comment 37 by, Jan 24 2014

Can't promise that it will work but I will give this a shot with the newly landed sendKeyEvents in the IME extension API.

My proposal is to make an extension that remaps the capslock key (whether it's on an external keyboard or not). Remapping options: Search, Ctrl, Alt, Disabled, Caps Lock. Any other remapping choices that would make sense?

Comment 38 by, Jan 24 2014

First try wasn't conclusive... We'll try to find out why.

Comment 39 by, Jan 24 2014

To give more details about the status: 

1. I can successfully remap* the capslock key but the default behavior (i.e. Caps Lock on/off) also kicks in. This is probably due to a special handling of this key in Aura.

2. I can see the remapped event but it doesn't apply to subsequent key events (e.g. impossible so far to perform ctrl-a via the remap capslock).

Comment 40 by, Jan 24 2014

Not a done deal but I believe that I have something that works.

I was able to workaround the capslock behavior kicking in: the capslock indicator will still show up but it has no effect on the input. Keyboard shortcuts work as expected AFAICT. I will try to wrap something hub this weekend and post it to for everyone to try.

Comment 41 by, Jan 24 2014

Status: Started

Comment 42 by, Apr 21 2014

Owner: ----
Status: Available
+xiangye new PM owner for text input on Chrome OS.

Comment 43 by, Feb 14 2015

Workaround from #11 worked for me. Thanks for sharing.

Comment 44 by, Apr 21 2015

Issue 450665 has been merged into this issue.

Comment 45 by, Apr 21 2015

Since the setting already exists, we only need a proposal for when to surface it.

The two cases that seem like clear wins to me are:
* A bluetooth keyboard is paired
* An external USB keyboard is attached (+rsadam who did work to detect that for TouchView). Though I believe some Chromeboxes come with external keyboards that also replace capslock with a Search key. Maybe we can only enable the setting if we detect a raw Capslock keycode from the keyboard?

Comment 46 by, Apr 21 2015

#45 - There is a plan¹ to distinguish external ChromeOS keyboards from external generic PC keyboards, for purposes including this and issue 175224 and generally being able to decide what a scan code means (e.g. F13 is "lock" on a ChromeOS keyboard but just another function key on other keyboards). The plan is to whitelist existing external ChromeOS keyboards by VID/PID, and have future ChromeOS external keyboards be recognizable by name (e.g. "ChromeOS" in the Product string). But I still don't know who owns the vendor external keyboard spec, and who can provide a list existing external ChromeOS keyboards.


To be clear, there's no problem *distinguishing* between Search and CapsLock — ChromeOS keyboards send the USB ‘GUI’ code for the Search key (which is the same code as the PC ‘Windows’ keys and the Mac ‘Command’ key). It's a question of identifying which keyboards *have* a CapsLock key.

Comment 47 by, Apr 21 2015

to #46 comment:
> It's a question of identifying which keyboards *have* a CapsLock key.

The task of identifying exact presence of the CapsLock key feels unnecessarily complex, *especially* in the face a simple fix[3]. Normally such complexity (dynamic settings pane) is worthwhile in the name of better UI[1], but not when such planning blocks a blatantly[2] broken UI today.

[1]: intended to reduce confusion when users have particular boards (ie: have --has-chromeos-keyboard) see here:
[2]: hidden settings:
[3]: stop hiding the setting[2], allowing users to fix the problem themselves. We'll only be undoing a fancy attempt at UX[1] improvements (to a most probably? power-user settings page), and when a proper fix is rolled out (like what you've suggested) we can turn the hiding[2] right back on.

Comment 48 by, May 21 2015

 Issue 418135  has been merged into this issue.

Comment 49 by, Jun 2 2015

"46 people starred this issue and may be notified of changes." -- I think this issue shouldn't be P3. Thanks to Dev Tools hack, I was able to remap "Caps Lock" today. Why don't we want to always show this option as proposed in #26? "Not elegant" solution is better than nothing.
Another solution is to make "Search" UI setting affect both "Search" and "Caps Lock" keys. That is what users want in majority of the cases.

Comment 50 by, Jun 12 2015

Labels: -Pri-3 Pri-1 M-46
Status: Assigned
It's ridiculous that this has sat around this long.

afakhry@ can you implement the solution from #17 soonish?

Comment 51 by, Jun 15 2015

Status: Started

Comment 52 by, Jun 16 2015

Project Member
The following revision refers to this bug:

commit df45c0b5db1a68a59ee5c7a64a522f6d2de67b39
Author: afakhry <>
Date: Tue Jun 16 02:54:14 2015

Enable options to remap CapsLock whenever an external keyboard is connected.

As per comments #16 and #17 on  issue 167237 , we will assume that most
external keyboards have a CapsLock key (chromeos external keyboards are
exceptions. However, there's no way to distinguish them at the moment).

This CL enables/disables the CapsLock remapping options in the keyboard
settings whenever there's an external keyboard is connected/disconnected

BUG= 167237 

Review URL:

Cr-Commit-Position: refs/heads/master@{#334538}


Comment 53 by, Jun 16 2015

Labels: week-1525

Comment 54 by, Jun 16 2015

Status: Fixed
This should be fixed now. Connecting an external keyboard will always show the CapsLock remapping section of the Keyboard Settings.

Note that we current't don't have a way to tell if a keyboard has a CapsLock key or not.

Comment 55 by, Jul 1 2015

Status: Verified

Comment 56 by, Jul 13 2017

I have an Acer C720 with a built-in Caps Lock key above the Shift key.  I prefer to have Ctrl in this position.  It used to be possible to make the Caps Lock remapping control visible, via devtools in order to change this setting.

A recent update seems to have removed this setting entirely.  This creates two problems:
- I can no longer change Caps Lock to Ctrl on new accounts.
- On old accounts where I already made this swap, I'm now unable to change it back.
This leaves me stuck with irreconcilably different keyboard layouts on my different accounts.

I understand the desire to avoid confusion, but this seems completely broken. I think a better fix would be to either a) restore the Caps Lock setting control, but hide it behind some kind of Advanced Settings mollyguard; or b) restore the Caps Lock setting control but only make it visible on machines known to have a built-in Caps Lock key.

Comment 57 by, Jul 13 2017

This doesn't look right to me either. As far as I can tell, we only show the Caps Lock setting when an external keyboard is connected. I think we should additionally show it when a Chromebook with a non-standard keyboard (that likely has a Caps Lock key) is connected. That was the original focus of this bug.

Since this has been closed for two years, I've filed  issue 742613  to track showing the setting on these Chromebooks. Feel free to star that issue to follow its progress.

Comment 58 by, Jul 13 2017

Re #56: Can you please file a new bug mentioning your comments above, and post a link to it here?

As a workaround for you to get our of that bad state, can you temporarily connect an external keyboard, once you do, you should be able to see the entry that allows you to remap caps lock.

Comment 59 by, Jul 13 2017

Re #57: Thanks, derat!

Comment 60 by, Jul 17 2017

As a note for future readers, I'm guessing #56 meant to refer to something like an "Acer C7" (parrot), not the "Acer C720" (peppy) which AFAIK never shipped with Caps Lock. I could be wrong though.

Comment 61 by, Jul 17 2017

Actually I meant the C710.  Good catch.

Sign in to add a comment