[Nami] Observed "Fingerprints" setup screen in the add user flow on Nami device. |
||||||||
Issue descriptionCROS:11316.29.0/72.0.3626.22. Boards: Nami Please specify Cr-* of the system to which this bug/feature applies (add the label below). Steps To Reproduce: (1)Add user account (2)Continue flow till to desktop area. (3) Expected Result: Actual Result: Observed setup "Fingerprints" on add user flow. Feedback report: https://listnr.corp.google.com/product/208/report/85858512721 How frequently does this problem reproduce? (Always, sometimes, hard to reproduce?) Reproduced all Nami family. What is the impact to the user, and is there a workaround? If so, what is it? Please provide any additional information below. Attach a screen shot or log if possible. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Dec 26
Adding a couple people to CC to help find an owner.
,
Dec 27
Please note that the first M72 Beta is approaching. This issue is currently marked to block the first M72 Beta release for Nami devices.
,
Dec 28
abodeti@ - A couple questions: -Is this new to CROS:11316.29.0/72.0.3626.22 and not seen before? -Do any Nami devices have a fingerprint reader (I'm assuming they don't)? -What happens if the user tries to set up their fingerprint? Does it cause any crashes or other issues?
,
Dec 28
,
Dec 28
,
Dec 29
@dgagnon I saw this on my nami device since 11316.29.0 No It doesn't crash, it just asks me to put my finger on the Fingerprint Scanner and it looks like it thinks I'm using a Pixel Slate, at least the "animation" looks like it. Also wired: Instant Tethering was disabled for me before (on latest stable, beta and the dev versions before), since the dev version it is enabled on my nami device. I needed to enable the flag manually, since the dev version where I get the fingerprint setup I don't need to enable it manually anymore.
,
Jan 2
,
Jan 11
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.
,
Jan 17
(6 days ago)
Given that this was RBS for M72, I am assuming this is fixed?
,
Jan 17
(6 days ago)
[Auto-generated comment by a script] We noticed that this issue is targeted for M-72; it appears the fix may have landed after branch point, meaning a merge might be required. The owner of this bug should confirm if a merge is required here. If so, add Merge-Request-72 label and indicate which commits/CLs are to be merged. Otherwise, remove Merge-TBD label. Thanks. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 Deleted