Policy-set sign-in keyboards: Not all sign-in keyboards displayed for users without stored input method |
|||||
Issue descriptionFollowup to bug 373324 : When the following conditions are met: - The DeviceLoginScreenInputMethods policy is set, - the device is on the sign-in screen, - a user pod already exists on the sign-in screen, - a user pod is focused on the sign-in screen and - no last-used input method is stored for the user, not all input methods set by the DeviceLoginScreenInputMethods policy are displayed. Note that a special case of the conditions described above is the "user pod" for a public session - public sessions never have a last user input method stored for them. Except for the special case of public session user pods, it should be very hard to trigger this bug, because in M59+, policy-enforced input methods are re-enforced when entering the "Add Person" dialog, which leads directly into a user session. After this user session exits, there will be a last used input method. Technical details: - SigninScreenHandler::SetUserInputMethod fails to set a last-used input method. - It falls back to calling InputMethodManagerImpl::StateImpl::SetInputMethodLoginDefault. - As a consequence, InputMethodManagerImpl::StateImpl::EnableLoginLayouts is called - This takes all predefined "login layouts" and filters them - What should it do instead: It should always ensure that all policy-mandated login layouts are included.
,
May 24 2017
Sorry for not being specific enough, the sign-in screen is pretty complex :) What I'm talking about: On the sign-in screen, we have user pods for existing users and public sessions. When a user pod is focused (clicked), the keyboard layouts are re-set. The reason is that we want to provide the user's last used keyboard layout in addition to the policy-provided keyboard layouts. When a public session pod is focused, this logic is also run, but there is no "last used keyboard layout" for public session, so this fails and results in buggy behavior (in most cases, displays only one of the policy-set keyboard layouts, if there are multiple). This does not matter much because there's no input field on the public session pod. As soon as you focus a user's pod again or defocus the public session or click "Add Person", the keyboard layouts are corrected*. This issue could also happen if there was an existing user pod with no stored last-used-keyboard-layout, but I think this doesn't happen in practice (because we store the last-used-keyboard layout for every user). * Possibly there are cases in M58 where this does not happen, like jumping directly from the public session pod do "Add Person". This was fixed in M59 along with the user-session fixes we did there.
,
May 24 2017
,
May 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/29aab9cae70bc11865c1e7f6d21c873be57e4dd6 commit 29aab9cae70bc11865c1e7f6d21c873be57e4dd6 Author: Pavol Marko <pmarko@chromium.org> Date: Wed May 24 18:45:28 2017 Use policy-mandated input methods as default login input methods InputMethodManagerImpl::StateImpl::SetInputMethodLoginDefault should respect the policy-allowed input methods if these are set. This is significant e.g. when a user pod is focused on the sign-in screen which does not have a stored last-used input method. BUG= 725546 TEST=unit_tests --gtest_filter=InputMethodManagerImplTest.* Change-Id: Iced86016d7acba431e80e31b63a9bc360455d9e6 Reviewed-on: https://chromium-review.googlesource.com/513904 Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Commit-Queue: Pavol Marko <pmarko@chromium.org> Cr-Commit-Position: refs/heads/master@{#474372} [modify] https://crrev.com/29aab9cae70bc11865c1e7f6d21c873be57e4dd6/chrome/browser/chromeos/input_method/input_method_manager_impl.cc [modify] https://crrev.com/29aab9cae70bc11865c1e7f6d21c873be57e4dd6/chrome/browser/chromeos/input_method/input_method_manager_impl_unittest.cc
,
May 24 2017
Got it, thanks!
,
May 26 2017
,
Aug 1 2017
,
Aug 22 2017
As verfieid in M61.0.3163.56:9765.35.0 dev reks, this issue is not reproducible and believed to be fixed.
,
Sep 27 2017
Again verified no issue in M61.0.3163.108 9765.72.0 beta peppy. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by maxkirsch@chromium.org
, May 23 2017