Open
Bug 891814
Opened 10 years ago
Updated 1 year ago
form data is not updated but apparently cached at reload
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
NEW
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.
Reporter | ||
Updated•10 years ago
|
![]() |
||
Comment 1•10 years ago
|
||
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
Comment 2•6 years ago
|
||
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•6 years ago
|
||
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•6 years ago
|
||
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•6 years ago
|
||
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).
Assignee | ||
Updated•5 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
Updated•1 year ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•