Rework autofill to also use async/await #31
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Firehed
added a commit
that referenced
this pull request
Jul 28, 2024
#31 adjusted the assertion during sending errors back, and reintroduced the data race from canceling the autofill request due to starting a modal one (explicitly returning a failure to the continuation, clearing it out, and canceling the authController - which went back to sendError) This removes the assertion, since it was logically unsound, not to mention unhelpful. I've done another bunch of manual testing in a sample app and can no longer reproduce the issue. I'm not sure how to cover this in automated tests to prevent another regression, but I'll file a ticket in case someone finds a way.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As noted in #29, the initial design of the autofill interactions used a delegate-based system, rather than async/await like the modal APIs. This was based on an incorrect assumption (carried over from web, where it may also be flawed) on how promises resolve. Upon further experimentation, it seems perfectly fine and non-problematic to have a promise that might take minutes to resolve and not have it block other interactions.
This (breaking) change adjusts the autofill API to also use async/await instead of delegates. Client code is a lot more straightforward, and the internals become more reliable since a bunch of conditional paths are eliminated.
In the same vein, I've also added a new
.unsupportedOnPlatformerror code so that clients can have fewer availability checks, part of #30. The API as a whole is still#if'd to iOS+visionOS, but that will get lifted eventually in a separate PR (see #16).