Skip to content

enhance: Add an option to control browser-level autofill behavior on Windows #1649

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Legend-Master merged 4 commits into from
Feb 23, 2026
Merged

enhance: Add an option to control browser-level autofill behavior on Windows #1649

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
34345aa
feat(windows): add option to control browser autofill behavior
aoxiangtianyu-go Dec 31, 2025
2eadced
refactor(webview): use bool for general autofill setting
aoxiangtianyu-go Dec 31, 2025
b069e6c
docs: update with_general_autofill_enabled docs
aoxiangtianyu-go Feb 23, 2026
ebfc81f
docs: remove uncorrect description
aoxiangtianyu-go Feb 23, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .changes/general-autofill.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
---
'wry': 'patch:enhance'
---

Add an option to control browser-level autofill behavior on Windows.
42 changes: 42 additions & 0 deletions src/lib.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -792,6 +792,25 @@ pub struct WebViewAttributes<'a> {

/// Whether JavaScript should be disabled.
pub javascript_disabled: bool,

/// Controls the WebView's browser-level general autofill behavior.
///
/// **This option does not disable password or credit card autofill.**
///
/// When enabled, the WebView may automatically populate form fields using
/// previously stored data such as addresses or contact information.
///
/// If not specified, this is `true` by default.
/// Setting this to `false` preserves the default platform behavior.
Comment thread
aoxiangtianyu-go marked this conversation as resolved.
Resolved
///
/// ## Platform-specific
///
/// - **Windows**: Supported. On Windows, WebView2's autofill feature (called
/// "Suggestions") may not honor `autocomplete="off"` attributes on input
/// elements in some cases. When this option is `false`, that autofill
Comment on lines +807 to +809

@FabianLars FabianLars Feb 23, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oof i had a comment pending here for ages but didn't see that. Do you have some source or references for that issue? I don't think i heard about this before.

@aoxiangtianyu-go aoxiangtianyu-go Feb 23, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, thanks for checking! The behavior I mentioned is documented in the Wry issue #1535, which explains that WebView2’s “Suggestions” (autofill) may ignore autocomplete="off" on input elements in some cases.

In practice, i’ve observed this in clash-verge-rev/clash-verge-rev#5944 , where using autocomplete="new-password" still triggered autofill.

The Wry issue references the official WebView2 setting CoreWebView2Settings.IsGeneralAutofillEnabled as a way to control this behavior globally.

@Legend-Master Legend-Master Feb 24, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WebView2’s “Suggestions” (autofill) may ignore autocomplete="off" on input elements in some cases.

I can't really reproduce that though

where using autocomplete="new-password" still triggered autofill.

That sounds correct no? You asked the browser to trigger autocomplete with new-password

I think maybe we could remove this part from the docs, I don't mind adding this in the wry webview settings though

@aoxiangtianyu-go aoxiangtianyu-go Feb 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't really reproduce that though

I was able to successfully reproduce this issue in the clash-verge-rev/clash-ver#5944. However, when I created a brand new Tauri project to build a minimal reproduction case, I failed to reproduce it, and the root cause remains unclear.

That sounds correct no? You asked the browser to trigger autocomplete with new-password

This is not the intended behavior. According to the MDN documentation for the new-password attribute valuenew-password: "This may be used by the browser both to avoid accidentally filling in an existing password and to offer assistance in creating a secure password."
Additionally, MDN security implementation guide explicitly states: "If you are defining a user management page where a user can specify a new password for another person, and therefore, you want to prevent autofilling of password fields, you can use autocomplete="new-password"."
These documents clearly indicate that the intended behavior of new-password is to avoid unwanted autofill of existing passwords, rather than triggering autofill.

I think maybe we could remove this part from the docs, I don't mind adding this in the wry webview settings though

I will fully follow the decision on whether to remove this part from the docs or add it to the wry webview settings.

@pewsheen pewsheen Feb 24, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was previously handling an issue with autocomplete=off, where Chrome would ignore it if the input was named password or had the type password. But I'm unsure if this behavior exists in WebView2, as it's also Chromium-based.

These documents clearly indicate that the intended behavior of new-password is to avoid unwanted autofill of existing passwords, rather than triggering autofill.

Though this is not directly related to the issue, just curious.
I'm not quite understanding what you want to achieve with autocomplete="new-password"? I think giving it autocomplete="new-password" attribute is telling the browser to autofill with a new password from a password manager?
If your goal is to turn off the autocomplete, and if it is the logic from WebView2 that it will ignore autocomplete="off" in some specific fields, maybe setting general_autofill_enabled to false is the solution instead of setting autocomplete="new-password"?

@aoxiangtianyu-go aoxiangtianyu-go Feb 25, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If your goal is to turn off the autocomplete, and if it is the logic from WebView2 that it will ignore autocomplete="off" in some specific fields, maybe setting general_autofill_enabled to false is the solution instead of setting autocomplete="new-password"?

Exactly. Currently, Tauri and Wry do not expose ICoreWebView2Settings4::SetIsGeneralAutofillEnabled, so using autocomplete="new-password" in the frontend is merely a temporary workaround we're forced to use.

However, as we discussed, these frontend hacks are unreliable because WebView2/Chromium often overrides them. This is precisely why I initiated this PR: to provide a robust, native way to disable autofill at the WebView level during construction, rather than relying on inconsistent HTML attributes.

/// behavior will be disabled.
/// - **macOS / Linux / Android / iOS**: Unsupported and ignored.
pub general_autofill_enabled: bool,
}

impl Default for WebViewAttributes<'_> {
Expand Down Expand Up @@ -834,6 +853,7 @@ impl Default for WebViewAttributes<'_> {
}),
background_throttling: None,
javascript_disabled: false,
general_autofill_enabled: true,
}
}
}
Expand Down Expand Up @@ -1405,6 +1425,28 @@ impl<'a> WebViewBuilder<'a> {
self
}

/// Controls the WebView's browser-level general autofill behavior.
///
/// **This option does not disable password or credit card autofill.**
///
/// When enabled, the WebView may automatically populate form fields using
Comment thread
aoxiangtianyu-go marked this conversation as resolved.
Resolved
/// previously stored data such as addresses or contact information.
///
/// If not specified, this is `true` by default.
/// Setting this to `false` preserves the default platform behavior.
Comment thread
aoxiangtianyu-go marked this conversation as resolved.
Resolved
///
/// ## Platform-specific
///
/// - **Windows**: Supported. On Windows, WebView2's autofill feature (called
/// "Suggestions") may not honor `autocomplete="off"` attributes on input
/// elements in some cases. When this option is `false`, that autofill
/// behavior will be disabled.
/// - **macOS / Linux / Android / iOS**: Unsupported and ignored.
pub fn with_general_autofill_enabled(mut self, enabled: bool) -> Self {
self.attrs.general_autofill_enabled = enabled;
self
}

/// Consume the builder and create the [`WebView`] from a type that implements [`HasWindowHandle`].
///
/// # Platform-specific:
Expand Down
4 changes: 4 additions & 0 deletions src/webview2/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -581,6 +581,10 @@ impl InnerWebView {
}
}

if let Ok(settings4) = settings.cast::<ICoreWebView2Settings4>() {
settings4.SetIsGeneralAutofillEnabled(attributes.general_autofill_enabled)?;
}

if let Ok(settings5) = settings.cast::<ICoreWebView2Settings5>() {
settings5.SetIsPinchZoomEnabled(attributes.zoom_hotkeys_enabled)?;
}
Expand Down