feat(ios): textfield option to disable iOS autofill strong password handling - #8348
Merged
vtrifonov merged 2 commits intoMar 23, 2020
Conversation
Contributor
|
@NathanWalker would you, please, run |
Contributor
Author
|
@vtrifonov Api report committed now thanks 👍 |
NathanWalker
force-pushed
the
feature/ios-textfield-secure-autofill-handling
branch
from
March 23, 2020 02:37
9c5d419 to
5634b64
Compare
Contributor
|
test |
vtrifonov
approved these changes
Mar 23, 2020
NathanWalker
added a commit
that referenced
this pull request
Aug 7, 2020
…andling (#8348) * feat(ios): textfield option to disable autofill strong password handling * chore: api change report
|
Hello, this option doesn't seem to work anymore, here my code (Nativescript 8.6.1, @nativescript/angular@16.0.0) : <TextField
[hint]="'auth.signin.hint-password' | L"
autocorrect="false"
autocapitalizationType="none"
[(ngModel)]="input.password"
required
type="password"
returnKeyType="done"
[secure]="isPasswordHidden"
[secureWithoutAutofill]="true"
></TextField>iOS strong password suggestion appears even with this option. EDIT: .component.html <TextField
[hint]="'auth.signin.hint-password' | L"
autocorrect="false"
autocapitalizationType="none"
[(ngModel)]="input.password"
required
type="password"
returnKeyType="done"
[secure]="isPasswordHidden"
[secureWithoutAutofill]="true"
(loaded)="onPasswordTextFieldLoaded($event)"
></TextField>.component.ts import { EventData, isIOS, TextField } from '@nativescript/core';
/**
* Disable secure password proposition on iOS.
*/
onPasswordTextFieldLoaded(args: EventData): void {
const textField = <TextField>args.object;
if (isIOS) {
const uiTextField = <UITextField>textField.ios;
uiTextField.textContentType = UITextContentTypeOneTimeCode;
}
} |
This file contains hidden or 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
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.
PR Checklist
What is the current behavior?
This issue has been complained about in a variety of development circles even outside NativeScript and something we recently experienced as a problem on an app we were building.
Here's a few extensive discussions on the topic all of which offer several solutions:
None worked as reliably and bulletproof as the suggestion made in this answer:
expo/expo#2571 (comment)
What is the new behavior?
When an app desires to completely avoid the auto iOS strong password suggestion handling, developers can now specify
secureWithoutAutofill="true"vs. the standardsecure="true"property.Currently developers may use TextField as follows which may unexpectedly display the iOS autofill strong password suggestion:
Now developers can specify this new property as follows in areas of their app in which they know various input controls should not display such handling on iOS:
Here's a sample of what this iOS UI looks like for those that may not have encountered this before. For those that have with no idea how to completely disable (iOS does not offer an easy way to turn this off other than adjusting a device setting for the app on per user basis), this provides an easy way to guarantee iOS will not display this surprising and often unexpected experience.
