Open Bug 891814 Opened 11 years ago Updated 2 years ago

form data is not updated but apparently cached at reload

Categories

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

22 Branch
All
Linux
defect

Tracking

()

People

(Reporter: wolfiR, Unassigned)

References

Details

(Whiteboard: DUPEME)

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.
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.
Whiteboard: DUPEME
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.
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
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.
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).
Component: HTML: Form Submission → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.