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.
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.