Skip to content

Allow hidden_field(_tag) to accept a custom autocomplete value#53512

Merged
byroot merged 1 commit intorails:mainfrom
brendon:hidden-field-autocomplete
Nov 15, 2024
Merged

Allow hidden_field(_tag) to accept a custom autocomplete value#53512
byroot merged 1 commit intorails:mainfrom
brendon:hidden-field-autocomplete

Conversation

@brendon
Copy link
Copy Markdown
Contributor

@brendon brendon commented Oct 31, 2024

#43280 introduced an enforced autocomplete="off" to all hidden inputs generated by Rails to fix a firefox bug.

Unfortunately it's also a legitimate use-case to specify an autocomplete with a value such as username and a value on a hidden input. This hints to the browser that (in this example) the username of a password reset form is what we've provided as the value and the password manager can store it as such.

This commit only sets autocomplete="off" if another autocomplete value isn't provided.

Supersedes #47798 which didn't seem to be as elegant a solution and didn't have proper tests.

@rails-bot rails-bot bot added the actionview label Oct 31, 2024
# value="" onchange="alert('Input collected!')" autocomplete="off" />
def hidden_field_tag(name, value = nil, options = {})
text_field_tag(name, value, options.merge(type: :hidden, autocomplete: "off"))
text_field_tag(name, value, options.merge(type: :hidden).reverse_merge(autocomplete: "off"))
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.

Since the preceding options.merge call will create a new Hash instance, would it make sense to invoke the ! variant?

Suggested change
text_field_tag(name, value, options.merge(type: :hidden).reverse_merge(autocomplete: "off"))
text_field_tag(name, value, options.merge(type: :hidden).reverse_merge!(autocomplete: "off"))

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.

Could the Hash#with_defaults! alias work instead?

Suggested change
text_field_tag(name, value, options.merge(type: :hidden).reverse_merge(autocomplete: "off"))
text_field_tag(name, value, options.merge(type: :hidden).with_defaults!(autocomplete: "off"))

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.

Interesting. I didn't know about that alias. It does read better :)

Is there a reason not to use merge! also?

@brendon
Copy link
Copy Markdown
Contributor Author

brendon commented Nov 7, 2024

@seanpdoyle, did you need me to do anything else on this PR?

@seanpdoyle seanpdoyle added the ready PRs ready to merge label Nov 7, 2024
@seanpdoyle
Copy link
Copy Markdown
Contributor

@brendon as far as the code is concerned, I think this is ready.

Like you mentioned in the PR description, setting [autocomplete] to something other than "off" is a legitimate use case, and is different from the other issues cited in #47798. Since there was an ongoing discussion in that PR, I'm not sure what the next steps are.

@zzak as the author of #47798, what do you think the next steps should be?

@seanpdoyle seanpdoyle removed the ready PRs ready to merge label Nov 7, 2024
@brendon
Copy link
Copy Markdown
Contributor Author

brendon commented Nov 7, 2024

@brendon as far as the code is concerned, I think this is ready.

Like you mentioned in the PR description, setting [autocomplete] to something other than "off" is a legitimate use case, and is different from the other issues cited in #47798. Since there was an ongoing discussion in that PR, I'm not sure what the next steps are.

@zzak as the author of #47798, what do you think the next steps should be?

Thanks @seanpdoyle, I don't see that there's anything stopping this from being merged in regardless. It doesn't break existing behaviour, it allows one to set a custom autocomplete, and it also allows those that object to the compulsory autocomplete="off" to stop it by passing autocomplete: nil. Everyone wins :D

In saying that, there's probably room for another PR that adds a configuration option to disable the autocomplete="off" globally for those that don't want it. Seeing the alarmingly large number of places a hidden tag is created without using some kind of central tag generator, there's probably also scope to DRY all of that up at the same time.

rails#43280 introduced an enforced `autocomplete="off"` to all hidden inputs generated by Rails to fix a [firefox bug](https://bugzilla.mozilla.org/show_bug.cgi?id=520561).

Unfortunately it's also a legitimate use-case to specify an `autocomplete` with a value such as `username` and a value on a hidden input. This hints to the browser that (in this example) the username of a password reset form is what we've provided as the value and the password manager can store it as such.

This commit only sets `autocomplete="off"` if another `autocomplete` value isn't provided.

Supersedes rails#47798 which didn't seem to be as elegant a solution and didn't have proper tests.
@byroot byroot force-pushed the hidden-field-autocomplete branch from ccb06bb to 09daec6 Compare November 15, 2024 11:28
@byroot byroot merged commit e5ad9e7 into rails:main Nov 15, 2024
@brendon
Copy link
Copy Markdown
Contributor Author

brendon commented Mar 29, 2025

Just wondering why this fix hasn't been released yet? It doesn't break any existing behaviour :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants