[regression] Soft reload does not clean up user inputs like in D7 (Firefox only)

Could you check the priority level on this issue? I am not sure it is major priority. If this applies:

A bug that causes user input to be lost, but does not delete or corrupt existing data.

.. then it is major.

We faced this bug in our project too.
The issue is caused by the Firefox functionality that restores form data on a soft reload (see a Stackoverflow issue reporting the same).
This unfortunately happens also for the form_build_id hidden input, which is used to point to a specific cached version of the form build.
So, from a fresh load of a form page (where a field with cardinality N is present):

1. form is rendered and the form_build_id is populated with a value, let's say form-1st-build-id;
2. the user clicks on a button "Add more" which triggers the ajax callbacks;
3. Drupal returns a list of ajax commands, and one of them is the update_build_id command, which is going to replace the old build id with the new one, let's say form-2nd-build-id;
4. the user performs a soft refresh of the page;
5. Drupal gives back a new form, with a new form id form-totally-new-build-id

;

6. Firefox repopulates the fields that have been changed "by the user" in the previous page "version". This includes fields that were updated by Javascript, so also the form build id input, that gets restored back to the form-2nd-build-id value;
7. when the user clicks again the "Add more" button, Drupal receives the old form build id, so it loads the old build which already has 2 items for the widget, giving back a third one.

In our project we have a more complex form, with inline_entity_form fields and field groups, and the results were even more severe, having the wrong widgets rendered in place of the inline entity forms.

As explained in the Stackoverflow issue, this can be solved by setting the attribute autocomplete="off" to a field.
So my suggestion is to add this attribute to the form_build_id input.

This is very hard to be tested, as it doesn't happen on Chrome and Opera, so it needs manual testing.

Some good sleuthing here and it seems to resolve the issue. It would still be a good idea to figure out why Drupal 7 is not affected. Does it keep the same form build ID when AJAX requests occur?

But as we are able to write Javascript tests now, maybe it will be possible to reproduce the issue in a test?

That's quite unlikely since we are using PhantomJS which is based on Webkit to run the JS tests. The issue only occurs on Firefox.

I guess this is just a typo and the form build id will be restored back to the second one, right?

Thanks @hchonov, you are right. I fixed the comment.

It would still be a good idea to figure out why Drupal 7 is not affected. Does it keep the same form build ID when AJAX requests occur?

In Drupal 7 the form build id gets replaced only when "the cached form was rendered on a cacheable page" (includes/form.inc:540 and includes/ajax.inc:344). Drupal pages are uncached for logged in users or when a session is present (includes/session.inc:252).

@hchonov, the autocomplete functionality is provided by the browser and it's something that Firefox users expect from it. I think that disabling this completely in Drupal by default should be avoided, and it should be something project-specific maybe.
For example, in Firefox you can reopen a tab closed by mistake and get the simple fields filled back. If we turn this off on form level, the user will loose an expected functionality. It's the responsibility of the user to check the input before clicking a submit button.

Removing all autocomplete functionality is a UX regression but disabling it only for form_build_id sounds OK for me because it doesn't bring any regression to user interaction. It's just something hidden. This looks like a nice workaround.

I'm reposting the patch from #8 just for RTBC. This is good to go, IMO.

EDIT: It was manually tested by @hchonov and by me.

I also tested manually with Firefox 53.0. I can also confirm that the patch solves the issue. I am very impressed with the detective work that resulted in this simple solution, huge thanks @sardara!

Why do you think it would benefit users to disable this functionality? I think disabling this would be a bad usability regression. I personally rely heavily on this feature with some software that is very fragile from a usability standpoint (e.g. Jira with all its UI trickery). It's great to be able to make a mistake and returning back to the previous state without losing all my unsaved data.

BTW this is a feature that most modern browsers have: Chromium also restores form input when a form is reopened (e.g. by navigating to another page and then pressing the back button), but Chromium only replaces the visual form input elements and leaves the hidden form_build_id input alone, so it is not affected by this. On Chromium a soft reload clears the form state but that's browser specific and within the expectations of the browser's user base. It works fine when navigating away and back, or closing and reopening a tab.

If you _really_ want to clear your form state you can always do a hard reload or revisit the URL. This is consistent with normal browser behaviour.

If Firefox shouldn't reuse the user input on soft reload that is something that should be discussed on Bugzilla and fixed in Firefox itself. There are also addons available for Firefox that enforce hard refreshes for the people that like this functionality.

We shouldn't alter default behaviour of a browser. There are millions of people using Firefox, do we really want to dictate that for all of them their chosen browser's behaviour is "wrong" and we should "fix" it?

It's a shame that this is essentially untestable as we're working around a browser specific bug. I'm committing to 8.4.x for the moment just in case there are issues we've not identified yet.

Committed a83586c and pushed to 8.4.x. Thanks!

This was marked as to be ported with the intention to backport it to 8.3.x after some incubation time in 8.4.x. Since 8.3.x is in the meantime unsupported this is not needed anymore. This can be marked as fixed now.