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 23 users

Issue metadata

Status: Verified
Closed: Jun 2014
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug-Regression

issue 377987

Sign in to add a comment

Issue 376632: Keyboard defaults to US English in M35 (when ephemeral users are enabled)

Reported by, May 23 2014 Project Member

Issue description

Chrome Version: 35.0.1916.69
Chrome OS Platform: <Make/model of computer running Chrome OS>: Samsung Chromebox, Samsung 303 Chromebook, HP Chromebook 11, Acer C720P, Acer C7

Steps To Reproduce:
1.Set default keyboard to be non-US English 
2.Update to M35

Expected Result:

Keyboard at bootup should still be the non-US English language.

Actual Result:

Keyboard is US English. Logging in as a user changes to the correct keyboard input.

How frequently does this problem reproduce? (Always, sometimes, hard to

Reproducible in M35 by one member of the team if policy "Erase all user info, settings, and state after each sign-out" is enabled.

Logs available upon reques

Comment 2 by, May 23 2014

This is a serious pain in the backside as when our school devices update to 35 they all default to a US keyboard. Have restricted devices to 35 for now. Please fix asap.

Comment 3 by, May 26 2014

Labels: Needs-Feedback
Can you clarify what "Set default keyboard to be non-US English" means? How are you doing this, and at what point does the keyboard setting get reset - only when a new OS update comes in, when you reboot the device, etc?

Comment 4 by, May 26 2014

For us when any of our managed devices (ChromeOS management via GAFE), after update to Chrome 35 the keyboard on the login screen is US. Therefore, the @ key is in the wrong place and student shave to get the @ key by pressing shift-2. If the device is set to wipe user data on log off, the language defaults to US when they have logged on as well. So a user has to set the language to UK everytime. I have restricted all our devices to 34 until the issue is resolved (except the few that did up date.

This has happened on HP11's, C720's, Samsung 303, Samsung Chromeboxes and our new LG Chromebases.

Comment 5 by, May 26 2014

Apologies for being overly precise/obtuse, but what was the flow prior to this, for a brand new device out of the box? Were the devices defaulting to the UK keyboard automatically, or did you have to change a setting somewhere?

Comment 6 by, May 26 2014

When we enroll devices, the language is selected there - before the enrollment process. They all selected UK by default - all our devices have UK keyboards. Once enrolled devices have always been on a UK keyboard. Our oldest devices have been enrolled for abour 2 years and gone though numerous updates without issue. However, as soon as they update to 35 (none are at 35 out of the box - the LG Chromebases come with 34) - the kayboard language becomes US. You cannot change it at the login screen and there is no policy in the management console to set it in device policies (perhaps there should be). Hope this makes sense.

Comment 7 by, May 26 2014

Labels: Cr-UI-Input-Text-IME
Sounds like the login screen's input methods don't follow the VPD settings?

Comment 8 by, May 26 2014

Labels: ReleaseBlock-Stable
Status: Assigned

Comment 9 by, May 26 2014

Labels: -Pri-2 Pri-1

Comment 10 by, May 26 2014

Labels: -Type-Bug Type-Bug-Regression Iteration-108

Comment 11 by, May 26 2014

Re #6, can you please try "Power Wash" the device and then at the first screen while booting, whether the default language and keyboard settings are "US (United Kingdom)" and "UK"? Thanks

Comment 12 by, May 26 2014

>> "Erase all user info, settings, and state after each sign-out" is enabled.
>> If the device is set to wipe user data on log off, the language defaults to US when they have logged on as well.

So this issue only reproduces when ephemeral policy is enabled.

Assigning to shuchen@ for initial investigation.

Comment 13 by, May 26 2014

Summary: Keyboard defaults to US English in M35 (when ephemeral users are enabled) (was: Keyboard defaults to US English in M35)

Comment 14 by, May 26 2014

Sorry, my bad in #11, the language name should be "English (United Kingdom)".

Comment 15 by, May 26 2014

I am investigating this in parallel. I have a lumpy with a German keyboard. Downloading an M34 image as we speak.

Comment 16 by, May 26 2014

Re #11: These are enterprise devices. Power wash works for consumer devices only. To reset an enterprise device, you must do a full wipe.

Comment 17 by, May 26 2014

OK - I can - on holiday this week - so can try on a device next week. However, we have hundreds of machines and wiping them all an re-enrolling is not realistic. 

I have one device on the beta channel, when this went to 35 it did the same thing. I wiped that device (note - power washing is not an option for a managed device - you have to wipe the device) while it was on 35. upon restart the language showed at UK as did the first login screen. However, after logging off it went to US and stayed there - rebooting did not change the situation.

Comment 18 by, May 26 2014

Re #17: The one device with which you experimented is very interesting. Just so that I understand correctly: You wiped this device while it was running M35 already, you enrolled it again, the language suggested and the one you picked were UK - but after the first login/logout, things switched to US? Is this a correct summary?

Comment 19 by, May 26 2014

Yes - thats what happened. I don't think starting a fresh on 35 helps.

Comment 20 by, May 26 2014


Comment 21 by, May 26 2014

My device has a German keyboard. I enrolled in M34. The keyboard layout suggested was DE. I accepted this, proceeded to enroll and log in. Everything worked as expected - DE keyboard everywhere.

I then allowed the device to update to M35. After the reboot, the keyboard layout on the login screen had switched to US. When I signed in to my session, the keyboard layout was DE. After logging out, the DE layout persisted to the login screen. This means that in my situation, there is a bug but it can be worked around by logging and out once.

This device does not have the ephemeral users policy enabled. If my understanding of the original report is correct, for ephemeral users, the layout used in the session does not persist after logout. Thus, there is no way to persistently switch the login screen layout away from US. The workaround I used would not be available on such devices.

Comment 22 by, May 26 2014

I assume prefs::kHardwareKeyboardLayout (intl.hardware_keyboard) in Local State should contain all the information we need and is not properly applied.

Comment 23 by, May 26 2014

I didn't try to build M35 branch, but it looks like kHardwareKeyboardLayout is incorrectly checked to be 'login layout'.
So in InputMethodManagerImpl::SetInputMethodLoginDefault() call to GetHardwareLoginInputMethodIds always returns empty list.
It might be so because kInputMethods[] list is stored in XKB format, but kHardwareKeyboardLayout is already translated to extensions.

Comment 24 by, May 27 2014

Sorry I don't know how to effectively debug into such issue. By scanning throughout the code of SetInputMethodLoginDefault(), it will fetch prefs::kHardwareKeyboardLayout, if not empty, use it; else use the top keyboard of the current locale. So even if prefs::kHardwareKeyboardLayout is cleared, the locale should take effect.

alemate@/nkostylev@, do you have any ideas? The sign-in screen after wiping user data on log off is handled by or Thanks

Comment 25 by, May 27 2014

Another probability is when "wiping user data on log off", either Profile::InitChromeOSPreferences() is not called or IME extensions are being loaded in the background but sign-in screen shows before they have been loaded.

alemate@/nkostylev@, can you please help to analyze the problem as I'm not familiar with profiles and sign-in/log-in screens. I think the focus is about the difference between normal log off and "wiping user data on log off".

Comment 26 by, May 27 2014

Aside from epehemeral user logout, we also have the problem that the keyboard changes to US on the first after the update from M34 to M35. This should not be happening either.

Comment 27 by, May 27 2014

I guess the 2 problems caused by the same root cause. I'm trying to find a feasible way for repro and debugging.
Right now it's infeasible for me to debug the problem with the real repro steps (either epehemeral user logout, or upgrade M34 to M35, because I need to add logs and deploy dev image to device).

Btw, I'm wondering that once the keyboard changes to US unexpectedly, can user see other keyboard options in the system menu triggered from the right bottom tray?

Comment 28 by, May 27 2014

Our users can change the keyboard back to UK by clicking in the bottom right hand bit of the screen. If you go to language settings - the two options are UK and weirdly Australian with US keyboard. The Australian option with the US keyboard is the default after 35 update.

Comment 29 by, May 27 2014

Status: Started
>> Our users can change the keyboard back to UK by clicking in the bottom right hand bit of the screen. 

I guess this means that at least hardware input methods are processes properly but for some reason US keyboard is selected as the default one.

Comment 30 by, May 27 2014

I just repeated my experiment from #21 again. Here are some observations:

intl.hardware_keyboard = "xkb:de::ger"
int.initial_locale = "de"

(on both M34 and M35)

I enrolled using M34. The keyboard was German throughout. When I rebooted after the update to M35, the keyboard had changed to US. The tray menu allowed me to switch to German - German (and a few other US layouts).

Comment 31 by, May 27 2014

Can you please list all the keyboard options in the tray menu (and keep its order)? Thanks

Comment 32 by, May 27 2014

1) I wiped and restored the device using an M34 image. The device booted up in German, with a German keyboard layout. The layouts offered on the login screen, before enrollment were:

Deutsch - Deutsche Tastatur (selected)
Deutsch - Deutsche Neo2-Tastatur
Deutsch - Belgische Tastatur
Deutsch - Schweizer Tastatur

2) I logged in to a session that uses English as the UI language and back out. This switched the UI language to English but kept the German keyboard. The layouts offered were:

German - German keyboard (selected)
US keyboard
US international keyboard
US extended keyboard
US Dvorak keyboard
US Colemak keyboard

3) I updated the device to M35 and rebooted. The keyboard switched to US. The layouts offered on the login screen were:

US (selected)
German - German
US international
US extended
US Dvorak
US Colemak

4) I left the keyboard set to US and logged into to the same session as 2) above. This switched my keyboard to a German layout.

5) I logged out. The keyboard remained set to German. The layouts offered on the login screen were:

German - German (selected)

The device is an Alex with a German hardware keyboard layout.

Comment 33 by, May 27 2014

Thanks for the detailed info.

I double checked the code, and found out I was wrong in #24. If intl.hardware_keyboard is empty, it will create a "fallback" hardware keyboard which is 'US'.
I think most likely the bug is caused by intl.hardware_keyboard is empty before calling SetInputMethodLoginDefault().

So transferring the bug to alemate@ for root cause of why intl.hardware_keyboard is empty.

Comment 34 by, May 27 2014

Labels: M-35
Potential stable block. Assigning M-35 label.

Comment 35 by, May 27 2014

Royans - can we get a rough idea of number of units affected by this and what are all possible customer workarounds?  Agree we may need to raise this to a P0.

Comment 36 by, May 27 2014

I've added some debug:

InputMethodManagerImpl::SetInputMethodLoginDefault() : initial_input_method_id=''
InputMethodDelegateImpl::GetHardwareKeyboardLayouts(): return 'xkb:gb:extd:eng'
InputMethodUtil::UpdateHardwareLayoutCache(): cached_hardware_layouts_[0] = 'xkb:gb:extd:eng'
InputMethodUtil::UpdateHardwareLayoutCache(): hardware_layouts_[0] = '_comp_ime_jkghodnilhceideoidjikpgommlajknkxkb:gb:extd:eng'
InputMethodUtil::UpdateHardwareLayoutCache(): hardware_layouts_[0] = '_comp_ime_jkghodnilhceideoidjikpgommlajknkxkb:gb:extd:eng' is NOT Login layout.
InputMethodUtil::UpdateHardwareLayoutCache(): hardware_login_layouts_ is empty. Fallback method '_comp_ime_jkghodnilhceideoidjikpgommlajknkxkb:us::eng' is used.

So InputMethodUtil::IsLoginKeyboard() is wrong.
But it works inside user session (because User LRU Input Method is set correctly).
Still investigating.

Comment 37 by, May 27 2014

Here is log inside user session:
[23017:23017:0527/] SetUserLRUInputMethod(): manager->IsLoginKeyboard('_comp_ime_jkghodnilhceideoidjikpgommlajknkxkb:gb:extd:eng') = 1
[23017:23017:0527/] SetUserLRUInputMethod(): manager->IsLoginKeyboard('_comp_ime_jkghodnilhceideoidjikpgommlajknkxkb:ru::rus') = 0
[23017:23017:0527/] SetUserLRUInputMethod(): manager->IsLoginKeyboard('_comp_ime_jkghodnilhceideoidjikpgommlajknkxkb:fr::fra') = 1

So, the result for the same ID '_comp_ime_jkghodnilhceideoidjikpgommlajknkxkb:gb:extd:eng' is different.

Comment 38 by, May 27 2014

Blockedon: chromium:377987

Comment 39 by, May 27 2014

Blockedon: -chromium:377987

Comment 40 by, May 27 2014

Blocking: chromium:377987

Comment 41 by, May 28 2014


Comment 42 by, May 29 2014


Comment 43 by, May 30 2014

FYI. the fix is in CQ.

Comment 44 by, May 30 2014

Labels: M-36

Comment 45 by, May 31 2014

The fix has been just merged to M36. Need to verify on M36 beta.

Comment 46 by, May 31 2014


Comment 47 by, Jun 2 2014

Marking this as "Fixed", so TE will verify in M36 ToT.

Comment 48 by, Jun 3 2014

Test Update: Tested this on 5841.28.0;36.0.1985.45
Verified that the keyboard layout is set accurately 
1) On reboot immediately after stepping through OOBE
2) On the the sign in screeen when either the ephemeral mode|DontShowUserNamesOnSignin policies are set or when the DontShowUserNamesOnSignin setting is disabled int he sign in page. 
crbug/377987 some additional verification steps.

Comment 49 by, Jun 4 2014

Status: Fixed
The fix has been merged to M36 and M35.

Comment 50 by, Jun 4 2014

Project Member
Labels: Merge-TBD
Is there a merge required here?

Comment 51 by, Jun 4 2014

The merges have been done as in

Comment 52 by, Jun 5 2014

When can we expect a new release (Chrome OS Stable)?

Comment 53 by, Jun 5 2014

Can I just mention that the timezome also defaults PST. We can get around this by forcing the timezone in device policy - but have never previously needed to do this. Also will effected devices go back to the correct keyboard layout or will we have to wipe them. Have a HP11 that has this issue - moved via chrome management to beta - so on 36 - still need to press Shify - 2 to get the @ symbol to login.

Comment 54 by, Jun 5 2014

Please file a different issue on timezone.

There is a new feature:

So, if anything goes wrong, please describe in a new issue.

Comment 55 by, Jun 5 2014

OK - will do.

Re the Keyboard issue - it would be great if we could have a device policy to lock the keyboard layout. This is a big deal in education and even when it was working they could switch to Dvorak.

Comment 56 by, Jun 5 2014

For "it would be great if we could have a device policy to lock the keyboard layout", I think, we also need a different issue. Because this is probably tricky.
"pupils study ... French,   In Year 9 some students also study Spanish or Latin"

So it should be discussed what exactly "device policy to lock the keyboard layout" should do.

Comment 57 by, Jun 5 2014

Re #55: You will probably want something like  issue 373324  but for regular sessions.

Comment 58 by, Jun 5 2014

Status: Verified
Tested this on 5712.83.0;35.0.1916.152
Verified that the keyboard layout is set accurately 
1) On reboot immediately after stepping through OOBE
2) On the the sign in screeen when either the ephemeral mode|DontShowUserNamesOnSignin policies are set or when the DontShowUserNamesOnSignin setting is disabled int he sign in page. 
crbug/377987 some additional verification steps.

Comment 59 by, Jun 9 2014

When can we expect a stable release with this fix included?

Comment 60 by, Jun 12 2014

1 of 323 devices updated to 35.0.1916.155. So far so good...

Thanks for fixing!

Comment 61 by, Jul 14 2014

Labels: Hotlist-ConOps

Comment 62 by, Jul 22 2014

Are there any chances to integrate a device policy to lock the keyboard layout in Cpanel for regular sessions?

Comment 63 by, Jul 22 2014

There are no plans to add such a policy.

Comment 64 by, Jul 22 2014

Shame - this is the biggest gripe about Chromebooks from teachers. Kid
switch keyboard layout to Dvorak. Dead easy to lock down in windows......


The information in this e-mail, together with any attachments, is 
confidential. If you have received this message in error you must not print 
off, copy, use or disclose the contents. The information may be covered by 
legal and/or professional privilege. Please delete from your system and 
inform the sender of the error.

As an e-mail can be an informal method of communication, the views 
expressed may be personal to the sender and should not be taken as 
necessarily representing the views of Wheatley Park School.

As e-mails are transmitted over a public network, Wheatley Park School 
cannot accept any responsibility for the accuracy or completeness of this 
message. It is your responsibility to carry out all necessary virus checks.

Wheatley Park School is an academy owned and operated by Wheatley Area 
Learning Trust, which is an exempt charitable company limited by guarantee 
registered in England and Wales with registered company number 8979902 and 
its registered office is Wheatley Park School, Holton, Oxford. OX33 1QH.

Comment 65 by, Jul 22 2014

Please open a separate feature request for this.

Comment 66 by, Oct 21 2015

Labels: -Merge-TBD

Comment 67 by, Jan 14 2016

Hi all,

I admit, I did not read the whole thing here, but I think my problem is the same.
My new Chromebook was bought in France and it has French keyboard by default. 
I want to change it permanently to English-US. Is this possible?
Surely, it is possible per-user, but on a login-page it is set to French.

Could someone point to the right direction.

Comment 68 by, Jan 14 2016

You may need to power wash your device. During the oobe screen, make sure you choose English language and US keyboard.

Sign in to add a comment