PIN auth when PIN keyboard is hidden due to virtual keyboard being shown does not work |
|||||||
Issue descriptionChrome Version: (copy from chrome://version) OS: (e.g. Win10, MacOS 10.12, etc...) What steps will reproduce the problem? (1)Set up a numerical device lock PIN (2)In Chrome OS lock screen, try to enter PIN with keypad on lock screen, you are able to unlock (3)On the same lock screen, if you trigger the virtual keyboard and enter PIN, the same valid PIN won't unlock device What is the expected result? vk shouldn't show up when typing in device pin - the vk asks for Google password rather than the pin, which is very confusing What happens instead? virutal keyboard should be supressed and do not show up, since lock screen already has a keypad Please use labels and text to provide additional information. If this is a regression (i.e., worked before), please consider using the bisect tool (https://www.chromium.org/developers/bisect-builds-py) to help us identify the root cause and more rapidly triage the issue. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Aug 13
I believe this is currently WAI, as the text field prompt says "Password" and not "PIN or Password". IMO, we shouldn't suppress the virtual keyboard on the lock screen. Perhaps we can just allow users to type their pin with the virtual keyboard? agawronska@, could you please help triage this? I believe you worked a bit in the lock screen code. Thank you!
,
Aug 13
That's correct. Virtual keyboard is shown to allow user to input password as the prompt asks for 'Password'. I do not think we should suppress virtual keyboard, because it would prevent user from using password on tablet/detachable without keyboard attached. Allowing to input PIN with virtual keyboard is an option. jdufault@ for triaging. WDYT Jacob?
,
Aug 13
PIN should still work in this case. At the moment the logic assumes that no PIN keyboard visible means PIN cannot be used, which is faulty in this case.
,
Aug 15
Chatted with Omri - this is a regression. We suppressed virtual keyboard before. Users should still be able to enter the pin with the mini numeric keyboard on the screen (see attached) when virtual keyboard is suppressed. I think we should suppress VK if there's no other concerns. + rkc@
,
Aug 15
Right, PIN submit should work even if the PIN keyboard is hidden because the VK (virtual keyboard) is being shown. > Users should still be able to enter the pin with the mini numeric keyboard on the screen (see attached) when virtual keyboard is suppressed. I don't believe this is currently broken; I believe the buggy behavior is that if the PIN keyboard is hidden because the user tapped the text input field to show the VK, then typing PIN using the VK does not authenticate the user.
,
Aug 15
Yep, that is an issue, and our proposal is not show the VK at all so that it doesn't cover the pin keyboard. There's seems to be no need for VK to show up when people can already use the pin keyboard to put in the pin. Does this make sense?
,
Aug 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/04d6e4f79498bf85cdbf3aef52c91902c028a59c commit 04d6e4f79498bf85cdbf3aef52c91902c028a59c Author: Jacob Dufault <jdufault@google.com> Date: Wed Aug 15 22:34:49 2018 cros: Fix submitting PIN when VK is not shown. PIN is hashed differently, and this hashing needs to happen even if the PIN keyboard is not shown but the user can submit via PIN. Bug: 873328 Change-Id: I658d7343628c6d24a42179966f1aa3c54ed3a4a8 Reviewed-on: https://chromium-review.googlesource.com/1173257 Commit-Queue: Jacob Dufault <jdufault@chromium.org> Reviewed-by: Wenzhao (Colin) Zang <wzang@chromium.org> Cr-Commit-Position: refs/heads/master@{#583421} [modify] https://crrev.com/04d6e4f79498bf85cdbf3aef52c91902c028a59c/ash/login/ui/lock_contents_view.cc [modify] https://crrev.com/04d6e4f79498bf85cdbf3aef52c91902c028a59c/ash/login/ui/lock_contents_view_unittest.cc [modify] https://crrev.com/04d6e4f79498bf85cdbf3aef52c91902c028a59c/ash/login/ui/login_auth_user_view.cc [modify] https://crrev.com/04d6e4f79498bf85cdbf3aef52c91902c028a59c/ash/login/ui/login_auth_user_view.h [modify] https://crrev.com/04d6e4f79498bf85cdbf3aef52c91902c028a59c/ash/login/ui/login_auth_user_view_unittest.cc
,
Aug 16
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6634aadcea77bd3c833846f7990b01d6386539f0 commit 6634aadcea77bd3c833846f7990b01d6386539f0 Author: Jacob Dufault <jdufault@google.com> Date: Thu Aug 16 22:03:18 2018 cros: Eliminate duplicate Layout() calls when animating login auth views By merging the two separate methods, the control flow is simplified, which will help prevent any possible animation glitches if, for example, both PIN and public session are animating at the same time. Bug: 873328 Change-Id: Ia3faa9d60aba91996804fc1ee3f64030467a4a1a Reviewed-on: https://chromium-review.googlesource.com/1173393 Commit-Queue: Jacob Dufault <jdufault@chromium.org> Reviewed-by: Xiaoyin Hu <xiaoyinh@chromium.org> Cr-Commit-Position: refs/heads/master@{#583842} [modify] https://crrev.com/6634aadcea77bd3c833846f7990b01d6386539f0/ash/login/ui/lock_contents_view.cc [modify] https://crrev.com/6634aadcea77bd3c833846f7990b01d6386539f0/ash/login/ui/lock_contents_view.h
,
Aug 17
,
Aug 28
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by kejiashao@chromium.org
, Aug 10