891814 - form data is not updated but apparently cached at reload

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Wolfgang Rosenauer [:wolfiR]]

This is a bit cumbersome to explain but can be seen easily with Firefox and bugzilla.

If a bug is loaded in a page and is changed from someone else in the meantime even a reload won't update some fields (e.g. component) even if they were changed. Now if new data is entered into the bug and are submitted there even is no mid-air collision but the component gets changed back to the chosen value.
Only a shift-reload resets all data to the actual one.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is by-design: a simple reload does the same form-state restoration as back/forward in history do so that reloading doesn't lose the things you type in a form.

Comment 2

[Vincent Lefevre]

This design is broken as it silently yields unwanted changes as on:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81745

INVALID was silently changed to FIXED when I submitted

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81745#c4

after a reload.

Something must be done, like asking the user what to do when a conflict is detected, e.g. open the new version of the page in a new tab. Firefox could also detect whether a value has been modified by the user, so that it will accept the merge.

Comment 3

[Vincent Lefevre]

Actually, in my case, this was not even form-state restoration (well, I suspect that Firefox tried to restore the form state, but got confused, possibly due to the second menu that appeared after reload). One initially had:

Status: [UNCONFIRMED] | RESOLVED

and no second menu. Then it was changed to:

Status: UNCONFIRMED | [RESOLVED] | VERIFIED | CLOSED
        FIXED | [INVALID] | WONTFIX | DUPLICATE | WORKSFORME | MOVED

by another user. And after I did a reload and submitted a comment, it changed to:

Status: UNCONFIRMED | [RESOLVED] | VERIFIED | CLOSED
        [FIXED] | INVALID | WONTFIX | DUPLICATE | WORKSFORME | MOVED

Comment 4

[Vincent Lefevre]

Additional notes: This was with Firefox 52.2.0, and I did not see the RESOLVED / INVALID, as the reload changed the UNCONFIRMED to RESOLVED / FIXED. I noticed later that the bug had actually been changed to RESOLVED / INVALID by looking at the bug history.

Comment 5

[Vincent Lefevre]

It seems that the same issue occurred on https://dev.mutt.org/trac/ticket/3975#comment:9 (I was using Firefox ESR 52.3.0).