Canceling registration modal throws ConstraintError [271863184]

Fixed

Bug

Status Update

No update yet.

Description

va...@shopify.com

created issue #1

Mar 7, 2023 12:04AM

Component used: Credentials

Version used: 1.0.0-alpha03

Devices/Android versions reproduced on: Huawei P30 Pro (VOG-L29)

I have multiple Google accounts on my phone. After triggering the passkey registration modal, I pressed the "Cancel" button and I got a CreatePublicKeyCredentialDomException with ConstraintError instead of the expected CreateCredentialCancellationException

Here are some logs (PasskeyUtils is from my application):

03-06 18:59:09.005 19307 19307 I Fido    : [AuthenticateChimeraActivity] FIDO2 operation is called from com.shopify.arrive.debug [CONTEXT service_id=287 ]
03-06 18:59:09.007 19307 19307 I Fido    : [AuthenticateViewModel] Determining the attachment [CONTEXT service_id=287 ]
03-06 18:59:09.017 19307 19307 I Fido    : [AuthenticateChimeraActivity] onAttachmentUpdate [CONTEXT service_id=287 ]
03-06 18:59:09.018 19307 19385 I Fido    : [AuthenticateViewModel] StrongBox not needed. [CONTEXT service_id=287 ]
03-06 18:59:09.020 19307 19307 I Fido    : [AuthenticateChimeraActivity] Using default UserVerifier. [CONTEXT service_id=287 ]
03-06 18:59:09.023 19307 19307 I Fido    : [StringStoreKeyHandleCache] initU2fDeviceCache
03-06 18:59:09.023 19307 19307 I Fido    : [FidoApiImpl] updateTransaction is called for resume
03-06 18:59:09.099  1508  5553 I ActivityManager: Process com.huawei.skytone (pid 25789) has died: svcb SVC
03-06 18:59:09.099  1508  5553 W ActivityManager: Scheduling restart of crashed service com.huawei.skytone/com.huawei.android.vsim.service.VSimService in 1000ms
03-06 18:59:09.248 19307 19384 I Fido    : [RegistrationRequestHandler] Registering key via credential store.
03-06 18:59:09.304 19307 19307 I Fido    : [PasskeysCreationFragment] PasskeysCreationFragment is shown [CONTEXT service_id=287 ]
03-06 18:59:10.897 19307 19384 I Fido    : [RequestController] Timeout Runnable is removed, and timer is stopped.
03-06 18:59:10.901 19307 19384 I Fido    : [RequestController] Timeout Runnable is removed, and timer is stopped.
03-06 18:59:10.915 19307 19307 I Fido    : [FidoApiImpl] updateTransaction is called for pause
03-06 18:59:10.915 19307 19307 E Fido    : [FidoApiImpl] pauseSecurityKeyRequestController should not be called when SecurityKeyRequestController is null.
03-06 18:59:10.957 31580 31580 D PasskeyUtils: error:androidx.credentials.exceptions.publickeycredential.CreatePublicKeyCredentialDomException: Unable to get sync account.
03-06 18:59:10.957 31580 31580 D PasskeyUtils: domError:androidx.credentials.exceptions.domerrors.ConstraintError@8d8d7a9
03-06 18:59:10.979 19307 19307 I Fido    : [FidoApiImpl] updateTransaction is called for stop
03-06 18:59:10.979 19307 19307 E Fido    : [FidoApiImpl] finishSecurityKeyRequestController should not be called when SecurityKeyRequestController is null.

Comments

he...@google.com <he...@google.com> #2Mar 7, 2023 12:43AM

Reassigned to he...@google.com.

The internal systemBarsForVisualComponents right now only uses systemBars, which doesn't include the display cutout: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/internal/SystemBarsDefaultInsets.android.kt;l=24;drc=dcaa116fbfda77e64a319e1668056ce3b032469f

Updating to systemBars.union(displayCutout) should fix this, if that's a change we can make.

ap...@google.com <ap...@google.com> #3Mar 7, 2023 05:07AM

Thank you for looking into this! It would be crucial to get this right soon as the edge2edge project depends on handling this properly :)

he...@google.com <he...@google.com> #4Mar 7, 2023 07:37PM

Marked as fixed.

Not taking the display cutout into account will impact cars heavily, since some have very large display cutouts:

https://developer.android.com/codelabs/build-a-parked-app#10

pr...@google.com <pr...@google.com> #5Mar 22, 2023 08:23PM

Project: platform/frameworks/support
Branch: androidx-main
Author: Alex Vanyo <vanyo@google.com>
Link: https://android-review.googlesource.com/3422569

Add displayCutout to default Material insets

Expand for full commit details

Add displayCutout to default Material insets 
 
Relnote: "Adds displayCutout to the group of insets that Material 
components take into account by default, to avoid content overlapping 
with the display cutout. 
 
This is a behavior change that will impact how inset-aware 
components behave around a display cutout. This includes the default 
value of the WindowInsets parameter for inset-aware Material 3 
components, and the WindowInsets values provided in the component 
Defaults objects for both Material 2 and Material 3. 
If this change causes undesirable behavior, 
manually specify the WindowInsets parameter on a per-component basis." 
 
Fixes: 362508045 
 
Change-Id: I43ee9ad12db0450ebb9c65ce10d5c39d12628b6c

Files:

M compose/material/material/src/androidMain/kotlin/androidx/compose/material/SystemBarsDefaultInsets.android.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/MaterialComponentsInsetSupportTest.kt
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/internal/SystemBarsDefaultInsets.android.kt

Hash: 692b440ac97b1831d5b35aafff241a98aeeacb93
Date: Wed Dec 18 19:49:15 2024

sh...@gmail.com <sh...@gmail.com> #6Mar 23, 2023 07:52AM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.compose.material:material:1.8.0-alpha08
androidx.compose.material:material-android:1.8.0-alpha08
androidx.compose.material:material-jvmstubs:1.8.0-alpha08
androidx.compose.material:material-linuxx64stubs:1.8.0-alpha08
androidx.compose.material3:material3:1.4.0-alpha06
androidx.compose.material3:material3-android:1.4.0-alpha06
androidx.compose.material3:material3-jvmstubs:1.4.0-alpha06
androidx.compose.material3:material3-linuxx64stubs:1.4.0-alpha06

va...@shopify.com <va...@shopify.com> #7Mar 25, 2023 12:57AM

I also confirm that the issue still exists in 1.0.0-alpha05

va...@shopify.com <va...@shopify.com> #8Apr 4, 2023 05:20PM

I think the error type changed from ConstraintError to NotAllowedError for alpha05, but still not CreateCredentialCancellationException as expected.

he...@google.com <he...@google.com> #9Apr 4, 2023 09:26PM

It's possible that ConstraintError is thrown once the passkey flow is started. This is according to the webauthn spec:

"If the user does not consent, return an error code equivalent to "NotAllowedError" and terminate the operation."

"If the user exercises a user agent user-interface option to cancel the process" ... "Throw a "NotAllowedError" DOMException."

Therefore, for a passkey request, you should be ready to handle both the CancellationException and the PublicKeyCredentialException(ConstraintError) as a signal for user cancellation.

va...@shopify.com <va...@shopify.com> #10Apr 4, 2023 10:01PM

Therefore, for a passkey request, you should be ready to handle both the CancellationException and the PublicKeyCredentialException(ConstraintError) as a signal for user cancellation.

You mean NotAllowedError?

he...@google.com <he...@google.com> #11Apr 4, 2023 10:02PM

Oops good catch. Yes by ConstraintError I meant NotAllowedError