Form restoration interop

[annevk]

As discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=654072 it might be good to have more alignment about what form restoration entails. Questions that came up:

• Is disabled restorable state?
• Should restoration happen on "soft" reload?
• Should there be an event? It sounds like pageshow might be good enough for this, provided things are restored at that time. As noted in Clarify that form state restoration does not fire events #7283 it seems developers could also use formStateRestoreCallback for this, which makes it very observable when exactly this process takes place...

Further context: #6853 (comment).

cc @gijsk @whatwg/forms

[calebdwilliams]

Not sure if there has been any movement on this that hasn't been tracked on here specifically, but I would argue for

Is disabled restorable state

that for the custom element reaction, that specific state should be opt-in-able via the state previously set on ElementInternals.prototype.setFormValue since that method accepts both a form value and a state. Although it appears as if even Chrome is no longer calling formStateRestoreCallback with the previous state, only the value(warning: overly-simplistic demo).

What I'm confused about (and maybe this is a separate issue) is how, exactly, the formStateRestore reaction should be triggered in the case of autocomplete. This is beginning to be an issue for the teams I support. If this is the right place to discuss that behavior, let me know; otherwise, I'd be happy to create a new issue.

[rvetrsek]

Hi,

I noticed that this issue might be causing problems like hydration mismatches when using a framework like Nuxt JS and UI components libraries (e.g., Nuxt UI). For example, setting a loading state on a button or another form component would also apply disabled = true, causing a hydration mismatch when reloading the page.

I put together a StackBlitz test in which I made two custom components (CustomButton and CustomButtonWithoutDisabled). The first one will put the button in a loading and disabled state when its property loading is set to true. The second one will just put it in a loading state—add a spinner and some styling. Upon reloading the page, the CustomButton component will have a hydration mismatch, while the CustomButtonWithoutDisabled component has no issue.

My opinion on the matter is that caching the disabled state should be in line with what other browsers are doing. If not, it causes unexpected behaviour only in Firefox, and developers need to create workarounds for one browser. Also, those workarounds might not always be straightforward when using libraries.

I also opened a related issue on the Nuxt framework repo before realizing this might be a browser problem.

Nuxt JS issue: Hydration issue in Firefox #31296
StackBlitz example: StackBlitz