User website should be allowed to be empty

[ErisDS]

Currently, the validations on both the client and server side are checking to see if the website is a valid URL, but they are not taking into account that the website is allowed to be empty.

Additionally, the website field gets autofilled by chrome with my email address, which is not a valid URL:

[jaswilli]

Nice catch.

Noticed a couple other issues when I was looking at this:

• UserValidator does not return validation errors for active users.
• Validations are being run twice for active users.

@ErisDS I'll fix these unless you're already on it.

[ErisDS]

S'all yours 👍

[jaswilli]

@ErisDS Thoughts on the autofill issue? That input has a type="url" on it, so it seems like maybe it's Chrome remembering something about that field from the past?

[PaulAdamDavis]

@jaswilli FWIW, I have the exact same issue. I did take a brief look. autocomplete="off" has no affect, on the form or input. I didn't go any further,

[ErisDS]

I think we still need to turn autocomplete off here if possible.

[jaswilli]

Sorry, I didn't mean to not address that part of the issue... I can't get Chrome to autofill this form at all so I wasn't able to figure out what was going on.

I did a little research and it appears as though <form> and <input> should support autocomplete="off" but also that browsers (Chrome especially) just kind of do whatever they want regardless.

That said, I'm going to add autocomplete="off" to the form on this page and we can see how that goes.

[JohnONolan]

Merged and closed - but the person who submitted the PR couldn't reproduce the issue and the person who merged didn't test it?

This had zero effect and is not resolved.

The proposed fix technique seems to have worked in the past - https://core.trac.wordpress.org/ticket/24364 - but that is no longer the case. I can't find anything on SO or elsewhere to suggest how to get Chrome to respect the proper attributes. Bit of a mystery.

[JohnONolan]

Assigning to @PaulAdamDavis cause I know he can reproduce

[ErisDS]

@JohnONolan you missed the extensive discussion of this issue on the associated pull request: #3297

It appears to be a chrome bug.

[JohnONolan]

I didn't miss it. I think you've misdiagnosed what the chrome settings are:

The first "autofill" only applies to predetermined user profile fields (nothing to do with user/pass) - and has no bearing on this issue.

The second "save passwords" only applies to user auth data and will always function while it contains records for a site (click on "Manage passwords"). Checking and unchecking the box simply enables and disables the saving of new passwords.

So overall: It's certainly annoying behaviour by Chrome, but I'm not convinced yet that it's unintentional, nor that they're going to change it. Regardless, this issue still exists and if we close this issue then we have no way of tracking it.

[ErisDS]

@JohnONolan And I didn't not test it. In fact I tested and researched it extensively.

My screenshot is intended to show the following:

• There is no global setting to turn off 'autocomplete' only to turn off 'autofill' and that doesn't affect autocomplete (it is suggested here that it does: https://yoast.com/autocomplete-security/)
• As we already know, none of the HTML properties are honoured by chrome.

Additionally - the only way I have found to prevent Chrome from pre-filling/autocompleting that field is to not include an id or name attribute, which is not a viable solution, or to use an incognito window - also not viable.

That is with all settings disabled, my chrome account logged out, all my data cleared, everything I can think of (short of resetting chrome to default settings) to prevent this at the browser level, as well as every combination I could think of of changing the id, the name, and the type of the input field.

I also tested out the autocomplete type property again suggested here: https://yoast.com/autocomplete-security/ and described here: http://wiki.whatwg.org/wiki/Autocompletetype

My suggestion is that if there is no way to disable this or prevent it at a browser level, that it is incredibly unlikely that there is a way to fix it with HTML alone.

We can leave this issue open by all means, but it's not like I haven't tried to find a solution.

[JohnONolan]

There already is a solution in the Trac ticket I linked to. It's not pretty, but it certainly works...