Redmine

Given the following flow with each of the users using the Firefox browser:

• User A opens issue 42 (for viewing, the issue edit form is already rendered hidden)
• User B opens issue 42 and changes the version field (or any other select box)
• User A becomes aware of the change (e.g. via notification mails) and soft-reloads the issue view (F5 in Windows)
• User A adds an issue note.

With the last update of User A, they inadvertently also update the Version field back to the value it had when User A first loaded the issue in step 1. The cause of this is a peculiarity of how Firefox handles changes on forms with soft reloads. This is described on https://bugzilla.mozilla.org/show_bug.cgi?id=1279253. What happens here is that Firefox ignores the changed selected value on select box and always retains the value it had on first load, even if the value was never actually changed by the user.

Unfortunately, this results in unwanted behaviour of the issue form (and possibly all other forms using select boxes like the project or admin settings). If users are not very carefully, they might inadvertently overwrite values. This problem is not really detectable on the server since the values sent by Firefox are valid. Here, it looks like the user just changed the value back.

After a couple of tests, it appears that Firefox takes the name attribute of a form tag into account to detect values of existing forms on reload. If the name value changes, firefox doesn't take any changed values into account and assumes that the newly loaded form is completely different. The attached patch leverages this behaviour by adding a random name attribute to all rendered forms. For Firefox, this results in no form values being preserved on reload. Since Redmine already asks for confirmation on leave, this isn't much of a loss probably.

The name attribute does not appear to be actually used for anything else and is thus save to be used here. Still, we preserve any explicitly set name attribute.