lost changes when editing several entries to one bug

RESOLVED INVALID

Status

()

--
major
RESOLVED INVALID
13 years ago
12 years ago

People

(Reporter: Leufkes, Unassigned)

Tracking

Details

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

We have recognized several times (but not always) on our bugzilla installation
that when changing entries to a bug not all changes are saved:
Example:
- changing status, comment and flag status -> new flag status not saved after
submit (only bug status and comment)
- changing status, comment and flag status -> new bug status is not saved after
submit (only flag status and comment)

It seems that this problem only appers when the change include a flag status
change. The problem does not appear every time, but often.

This behaviour is a big problem for us, because we can not be sure that bugzilla
 saved all changes made to a bug and have to verify it every time changes are
submitted.

Reproducible: Sometimes

Steps to Reproduce:
1. changes several itmes to a bug (like Status, cc, comment plus! flag status)
2. submit the bug
3. check the bug for the changes made
(Reporter)

Updated

13 years ago
Version: unspecified → 2.18

Comment 1

13 years ago
Yes, I'm fairly sure I know this problem. I have a few questions for you:

1) Are you using Apache on Linux?
2) Are people closing their browser window before the process_bug.cgi screen is
complete?
(Reporter)

Comment 2

13 years ago
(In reply to comment #1)
> Yes, I'm fairly sure I know this problem. I have a few questions for you:
> 
> 1) Are you using Apache on Linux?
> 2) Are people closing their browser window before the process_bug.cgi screen is
> complete?

1) Yes,
Red Hat Enterprise Linux ES release 3 (Taroon Update 4)
httpd-2.0.46-44.ent (<-- Apache version of the rpm)
2) No ;-) 

Comment 3

13 years ago
Which version of Bugzilla are you using? 2.18, 2.18.1 or 2.19.x? I fixed a
similar bug two months ago, see bug 290095. But only 2.19.x was affected, not
2.18.x. That's why I'm asking. ;)

This may have something to do with your inclusion list, see editflagtypes.cgi.
If this list is empty for some given flag type, then flags of this type should
not be displayed. As I mention in bug 290095 comment 0, these flags are not saved.
(Reporter)

Comment 4

13 years ago
(In reply to comment #3)
Our BZ version is 2.18rc2.

Does bug 290095 explain that other bugitems than flags (like a included bug
status change) are not saved ?

Comment 5

13 years ago
(In reply to comment #4)
> Does bug 290095 explain that other bugitems than flags (like a included bug
> status change) are not saved ?

No.

Could you try to upgrade to 2.18.1 and tell us if the problem still appears?
(Reporter)

Comment 6

13 years ago
I will try to update to 2.18.1 next week.

(In reply to comment #1)
> Yes, I'm fairly sure I know this problem. I have a few questions for you:
> 
> 1) Are you using Apache on Linux?
> 2) Are people closing their browser window before the process_bug.cgi screen is
> complete?

I there a problem with our apache version ?

Comment 7

13 years ago
(In reply to comment #6)
> I there a problem with our apache version ?

I don't think so. mkanat, what do you had in mind when asking this question?

I'm also setting the OS to Linux as you mentioned RHEL in comment 2.
OS: Windows XP → Linux

Comment 8

13 years ago
(In reply to comment #7)
> I don't think so. mkanat, what do you had in mind when asking this question?

  I just wanted to see if he was experencing timeout errors, perhaps.
(Reporter)

Comment 9

13 years ago
i have testet this with version 2.18.1 an its the same behaviour.

Updated

13 years ago
Keywords: qawanted

Comment 10

13 years ago
Suggest confirming.  I've experienced this myself on b.m.o.

Comment 11

13 years ago
(In reply to comment #10)
> I've experienced this myself on b.m.o.

We need a testcase

Comment 12

13 years ago
(In reply to comment #11)
> (In reply to comment #10)
> > I've experienced this myself on b.m.o.
> 
> We need a testcase

Until I do more checking, this is the best that I can give right now:

On bug 300403, at 14:01 on 2005-07-25, I submitted attachment 190455 [details] [diff] [review], marking it review+.  Once I 
returned to the regular show_bug screen, I changed 4 things:  I changed the status to ASSIGNED, I 
cleared the status whiteboard, and I requested approval and approval2.20.  When I committed, the flag 
changes were ignored, and a minute later I had reloaded the page (which properly showed the change 
in status and whiteboard), requested the flags again, and this time the flags were properly set.

Comment 13

12 years ago
(In reply to comment #12)
> changes were ignored, and a minute later I had reloaded the page (which properly showed the change 
> in status and whiteboard), requested the flags again, and this time the flags were properly set.

"reloaded" seems to be the key point here. While talking with myk, it appeared that there is a bug in Firefox which incorrectly updates dropdown menus when reloading the page, meaning that some changes may not be taken into account.

I'm marking this bug as INVALID from a Bugzilla point of view (but is a valid Firefox bug, but there is a separate bug for that). Please reopen if you see this problem again *without* ever reloading the page.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Keywords: qawanted
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.