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

[aoxiangtianyu-go]

close #1535

This PR adds an optional WebView attribute to control browser-level autofill behavior on Windows.

The motivation for exposing this option is that browser-level autofill behavior in WebView2
is controlled by the underlying runtime and cannot always be influenced through standard
HTML attributes alone. In some scenarios, applications need a way to explicitly opt out of
browser-managed autofill at the WebView level.

The default behavior is preserved unless the option is explicitly set.
The change is limited to the WebView2 implementation and does not affect other platforms.

Related issues

• Expose IsGeneralAutofillEnabled WebView2 setting #1535
• Clear saved info clash-verge-rev/clash-verge-rev#5944

Follow-up

I will submit a separate PR to tauri to expose this API at the application level.

[FabianLars]

thanks for the PR! just some nits :)

[aoxiangtianyu-go]

I’ve addressed the review feedback and pushed the updates. Please let me know if there’s anything I should do.
Thanks!

[aoxiangtianyu-go]

Thanks for the feedback! I'm currently on Chinese New Year holiday.
I will address the changes after the holiday.

[aoxiangtianyu-go]

Thanks for the review!
I've updated the docs to reflect the default value and clarified that password and credit card autofill are not affected.

[aoxiangtianyu-go]

OK Thanks!

[github-actions]

Package Changes Through ebfc81f

There are 1 changes which include wry with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
wry	0.54.2	0.54.3

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[Legend-Master]

Thanks

[FabianLars]

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]

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]

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]

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]

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]

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.