Bug 475802 - flags reset w/o mid-air collision warning
flags reset w/o mid-air collision warning
Status: CLOSED UPSTREAM
Product: Bugzilla
Classification: Community
Component: Creating/Changing Bugs (Show other bugs)
3.6
All Linux
high Severity medium (vote)
: ---
: ---
Assigned To: Simon Green
: Reopened
: 470562 511022 865760 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-10 10:23 EST by Bill Nottingham
Modified: 2014-10-12 18:45 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-01 18:54:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2008-12-10 10:23:44 EST
I was editing bug 472441, setting it to MODIFIED and adding a comment.

When I did so, it reset flags, without causing a mid-air collision warning.
Comment 1 David Lawrence 2008-12-10 11:31:28 EST
Sigh, i thought i fixed this with the the last update. Can you give me some more details such as:

1. Browser/Version?
2. Javascript on/off?
3. Did you simply click reload botton or did you do full reload (shift-reload)?
4. The only change was the status change?
5. Any other details you can give...

Thanks
Dave
Comment 2 Bill Nottingham 2008-12-10 11:46:24 EST
(In reply to comment #1)
> 1. Browser/Version?

firefox-3.0.4-1.fc10.x86_64

> 2. Javascript on/off?

On.

> 3. Did you simply click reload botton or did you do full reload (shift-reload)?

I think I just went to the URL bar and hit enter, or clicked on the
'Bug  472441' link already on the page from a previous change.

> 4. The only change was the status change?

No, added a comment too.
Comment 3 David Lawrence 2008-12-15 13:39:23 EST
Hmm, I am not able to reproduce the way you have described. If you had made a previous change and let the page stay that way til your next change, your URL window should have https://bugzilla.redhat.com/process_bug.cgi. Simply hitting enter on that URL would generate a different message/error. If you click on the bug id in the page, it should have been the same as reloading the page from scratch and it should have shown the new updated flag values. Is there way you can try to reproduce this with Sly and see if you can recreate it again?

Dave
Comment 4 Bill Nottingham 2008-12-16 10:05:35 EST
I don't have a bug at the moment that would do this, no. I'll reopen if it comes back.
Comment 5 Stepan Kasal 2009-05-08 08:52:28 EDT
Hi, I have experienced this today, with bug #483073
Answers to questions from comment #1:
1. firefox-3.1-0.11.beta3.fc11.i586
2. Javascript on
3. -- none of that, see below for details
4. Status change was the only intended change.
It seems that I have also touched the listbox attached to rhel-5.4.0 flag, changing "-" to empty.

What happened:
1. I opened a tab with the bug few days ago.
2. Noticing that I miss some acks, I contacted all the managers to acquire them.
3. Today, I returned to that tab, changed the status to MODIFIED and hit "Commit"
4. All the flags got cleared.

Obviously, my first idea is what the Summary of this bug says:
"Mid-air collision was not detected when the only changes that happened in the meantime were changes to the flags field"

In the meantime, I have edited several other bugs, probably from two different computers.  Additionally, more things might have happened (I do not remember exactly):
- I might have touched some of the flag listboxes looking whether I can set "+" or not.  Actually I probably did change "rhel-5.4.0-" to nothing, see below.
- I might have started writing a comment and then deleted it
- I might have change my bugzillla password from a second computer (and logged in again from the first computer, from a different tab)

Looking at the history, I deduce that there was "rhel-5.4.0-" at the time of the page load.  The unfortunate commit today has removed "rhel-5.4.0+"; so I deduce I must have touched that flag box changing it from "-" to nothing.

IMVHO, bugzilla should warn each time when the bug has changed since the tab was loaded.  Are there reasons against this simple solution?
Comment 6 David Lawrence 2010-01-15 11:54:37 EST
Red Hat Bugzilla is now using version 3.4 of the Bugzilla codebase and
therefore this bug will need to be re-verified against the new release. With
the updated code this bug may no longer be relevant or may have been fixed in
the new code. Updating bug version to 3.4.
Comment 7 David Lawrence 2010-08-25 17:42:21 EDT
Red Hat has now upgraded to Bugzilla 3.6 and this bug will now be reassigned to that version. It would be helpful to the Bugzilla Development Team if this bug is verified to still be an issue with the latest version. If it is no longer an issue, then feel free to close, otherwise please comment that it is still a problem and we will try to address the issue as soon as we can.

Thanks
Bugzilla Development Team
Comment 8 Tomáš Bžatek 2011-03-31 11:09:58 EDT
Seeing this too, comment 5 is close to what I see.

I.e. having page loaded with ack? and sending updated Technical field would also submit my flags, overriding those ack+ which I got from other people meantime. No mid-air collision page displayed.
Comment 9 Ales Zelinka 2011-08-05 11:21:58 EDT
Happens to me 2-3 times per release, that my qa_ack+ is reverted because of this and I have to re-ack. 

> IMVHO, bugzilla should warn each time when the bug has changed since the tab
> was loaded.  
Can we please have this implemented?
Comment 10 Simon Green 2011-08-15 20:24:15 EDT
(In reply to comment #8)
> Seeing this too, comment 5 is close to what I see.


(In reply to comment #9)
> Happens to me 2-3 times per release, that my qa_ack+ is reverted because of
> this and I have to re-ack. 

Can you please let me know the bug numbers please?
Comment 13 Ondrej Vasik 2011-08-24 16:48:10 EDT
*** Bug 511022 has been marked as a duplicate of this bug. ***
Comment 19 Simon Green 2011-12-06 01:41:44 EST
I think we have a possible answer

https://bugzilla.mozilla.org/show_bug.cgi?id=89822
Changing multiple bugs fails to cause midair collisions 

Could this be the case with this bug?
Comment 20 Simon Green 2012-06-19 02:45:18 EDT
*** Bug 470562 has been marked as a duplicate of this bug. ***
Comment 21 Simon Green 2012-06-19 02:46:29 EDT
No one has been able to provide a use case where this can be repeated. Closing.

  -- simon
Comment 22 Ales Zelinka 2012-10-01 04:47:03 EDT
Reopening, Simon, is this caused by the "firefox doesn't refresh data on reload" bug fixed in v4.4 upstream?
Comment 23 Simon Green 2012-10-01 18:54:24 EDT
(In reply to comment #22)
> Reopening,

Reclosing.

> Simon, is this caused by the "firefox doesn't refresh data on
> reload" bug fixed in v4.4 upstream?

Yes.
Comment 24 Marcela Mašláňová 2012-10-15 07:26:42 EDT
Currently, we have Red Hat Bugzilla 4.2.3-4.1. The bug is still there #865760. I hope you are right and it will be resolved in v4.4.
Comment 25 Marcela Mašláňová 2012-10-15 07:27:06 EDT
*** Bug 865760 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.