hidden field autocomplete="off" is not anymore valid

[BalusC]

Originally reported in Faces project: jakartaee/faces#1912

As per latest HTML spec the autocomplete="off" is not anymore valid on hidden fields (e.g. view state, client window state).

It was originally introduced to work around Firefox specific behavior which was not observable on other browsers: #1133

Reproducer:

1. Open Faces page with Ajax form (and inspect jakarta.faces.ViewState hidden input field and remember its value).
2. Perform Ajax submit.
3. Hard-Refresh page and inspect jakarta.faces.ViewState hidden input field. It should have a new value, not the one from the initially opened page.

This happened only in Firefox as per https://bugzilla.mozilla.org/show_bug.cgi?id=520561 and work around was to add autocomplete="off" to the hidden field.

Fast forward ~15 years, the specific attribute value of off is considered invalid as per Nu HTML validator https://validator.w3.org/nu/ as per recent changes in HTML spec https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill

We can turn off this work around via following context param:

<context-param>
    <param-name>com.sun.faces.autoCompleteOffOnViewState</param-name>
    <param-value>false</param-value>
</context-param>

The original problem is also not anymore reproducible in current Firefox versions (tested 124.0.2) so I think it's OK to make this config the default as per Mojarra 4.1. I.e. don't anymore render autocomplete="off" unless explicitly instructed as follows:

<context-param>
    <param-name>com.sun.faces.autoCompleteOffOnViewState</param-name>
    <param-value>true</param-value>
</context-param>

[pizzi80]

to simplify Faces configuration this could also be deprecated for removal... ?

[BalusC]

Yeah, it could indeed be deprecated for removal. But it's not part of API ;)

[pizzi80]

so we could delete the property and the associated logic ... ;P

[BalusC]

I'd rather not. Imagine that Firefox or any other browser somehow decides to resurrect this misbehavior. I think it's in long term better to change the autofill type. one-time-code sounds ideal but it's broken in older Firefox versions. Probably new-password but I have a very awkward feeling with this.

[melloware]

Yeah its easy enough to leave in the code. Its off by default now so its not harming anything to leave in.

[volosied]

@BalusC You said in Step 3: It should have a new value, not the one from the initially opened page.

I found that the new value is used when the page is refreshed in FireFox. However, in Safari / Chrome, the original value is displayed:

Pure HTML/JS code to replicate

      <form><input type=hidden name="test" value="original"></form>
      <button id=show>show hidden value</button><button
         id=update>Update value</button>
      <script>document.getElementById("show").addEventListener("click", () => { alert(document.querySelector("input").value) }); document.getElementById("update").addEventListener("click", () => { document.querySelector("input").value = "updated" })</script>

I was also able to reproduce the behavior above via JSF (client side state saving and an input within a c:forEach). The scenario I tested likely isn't very common, but it still proves that hidden field change is still possible.

I'm wondering which browsers are correct? Is it Firefox or the others. This is a behavior difference, and I could still see someone affected by this difference in functionality between browsers.

I'm leaning to revert this change if it can somehow break an application/users, as the HTML validation error is less severe.