Bug 838095 - Cached flags override expected settings
Cached flags override expected settings
Product: Bugzilla
Classification: Community
Component: User Interface (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: Matt Tyson
: Reopened
: 835930 846402 848668 850922 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2012-07-06 10:24 EDT by Marek Goldmann
Modified: 2012-10-24 19:48 EDT (History)
15 users (show)

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

Attachments (Terms of Use)

  None (edit)
Description Marek Goldmann 2012-07-06 10:24:17 EDT
Description of problem:

1. Someone submits something for review and he doesn't close the browser tab or window.
2. I'm starting the review by setting the fedora-review to ?.
3. Found some issues and asking for correction.
4. Package is updated by the packager.
5. Package is good to go, I set fedora-review to +.
6. Packager refreshes the page and the fedora-review flag is correctly set to +. He clicks on "Edit" to edit the flags and the drop-owns pop up where >>fedora-review is set to ?<<. Of course nobody sees this, so packager is changing the fedora-cvs flag to ? and saves.
7. Of course both, fedora-revew and fedora-cvs are now set to ?.
8. You try to process the request, but you see that both, fedora-review and fedora-cvs are set to ? by the packager, not the reviewer. 

Version-Release number of selected component (if applicable):

Current production version.

How reproducible:


Steps to Reproduce:

See above.
Actual results:

Flags are cached.

Expected results:

Flags set properly.
Comment 1 Simon Green 2012-08-16 00:23:48 EDT
*** Bug 835930 has been marked as a duplicate of this bug. ***
Comment 2 Simon Green 2012-08-16 00:24:00 EDT
*** Bug 846402 has been marked as a duplicate of this bug. ***
Comment 3 Simon Green 2012-08-16 00:25:48 EDT
I looked at this last year and we were unable to reproduce it. Now we have a new dev on board, I'm assigning this one to him to see if he can reproduce it, given we have step by step instructions to reproduce it (something we didn't get before hand).

  -- simon
Comment 4 Simon Green 2012-08-16 21:48:54 EDT
*** Bug 848668 has been marked as a duplicate of this bug. ***
Comment 5 Simon Green 2012-08-28 21:06:17 EDT
*** Bug 850922 has been marked as a duplicate of this bug. ***
Comment 6 Simon Green 2012-08-29 02:03:27 EDT
(In reply to bug 850922 comment #2)
> I never got Step 7.  No mid-air collision was given.  That is the error I'm
> reporting in this bug.

Suzanne: Can you provide us with how you can reproduce this bug?

  -- simon
Comment 7 Suzanne Yeghiayan 2012-08-29 17:00:14 EDT
Happened again.  See https://bugzilla.redhat.com/show_activity.cgi?id=848742
I need to add this bug to the python-rhsm advisory and someone had put the bug into the ON_QA status, where ET won't let me add it. 
So all I did was change the status from ON_QA to MODIFIED and it cleared the rhel-5.8.0+ and blocker+ flags.
Comment 8 Matt Tyson 2012-08-29 21:09:42 EDT
This isn't a bug in Bugzilla.  It's the behavior of Firefox.

Firefox has two page refresh modes, a "soft refresh" and a "hard refresh"

The soft refresh will cache form data between a page refresh, one of these things is the flag status.  When you get a mid-air collision, hit the back button and refresh the page, Firefox will maintain the previous form data, in this case it's the flags staying set in their prior state.

After the back button, page refresh sequence you'll see the "Flags: (edit)" section say fedora-review +, but when you click edit and expand the section you will see that fedora-review  is set to ?.  This is because Firefox is caching the form data.

If you view the HTML source you'll see that the (for example) fedora-review flag is set to fedora-review+ in the source, but in the form it's still on fedora-review?

Bugzilla in this case is generating the page correctly

This appears to be a long standing issue in Firefox and is regarded by the firefox devs as the correct behavior. See this bug for more information ( https://bugzilla.mozilla.org/show_bug.cgi?id=46845 )

Suggested workarounds

1) Use Chrome.  I can't replicate this bug in Google Chrome or Konqueror.  Both browsers correctly refresh the page.
2) Don't use the back button. Click the link to the bug on the collision page.  This will reload the page from scratch.
3) Force a hard refresh (shift refresh, ctrl-shift-r, ctrl-f5)
Comment 9 Kevin Baker 2012-08-31 12:15:58 EDT

is it work contacting dkl to see if he had something in place for this? In the last two months I've seen a lot of reports about this. Doesn't mean it wasn't happening before but I'm wondering if we backed out a fix dkl might have had in there. Can't imagine what though.

Comment 10 Tomas Mraz 2012-10-10 11:59:09 EDT
It's really weird, that it never happened to me a few months ago and now it started to happen. I think something had to change in either firefox or bugzilla that started to trigger this issue.
Comment 11 Marek Goldmann 2012-10-10 12:47:46 EDT
I'm seeing this issue since the big Bugzilla update that happened sometime ago.
Comment 12 Thomas Woerner 2012-10-17 12:05:06 EDT
Remember search and form history is disabled for me. 

browser.formfill.enable: false


browser.formfill.saveHttpsForms: true

This is bad and is a bug in firefox in my opinion.
Comment 13 Martin Kletzander 2012-10-17 12:28:02 EDT
Would there be a possibility to add a feature to our bugzilla that behaves similarly to the warnings "publicly accessible bug" and "mid-air collision"?  
There would be a page showing what changes you are about to make, so you could review those and incase someone doesn't like it, there would be a settings option to turn it off.  This would actually help with more than this bug and it's browser-indepedent.
Comment 14 Martin Kletzander 2012-10-17 12:29:13 EDT
(In reply to comment #13)
I'm of course willing to create new BZ for that request, but I don't want to take your time in case it's pointless.
Comment 15 Richard W.M. Jones 2012-10-19 13:16:20 EDT
Happens all the time on https://bugzilla.redhat.com/show_bug.cgi?id=829427.
Please fix.
Comment 16 Frank Ch. Eigler 2012-10-19 15:11:51 EDT
Would emitting cache-disabling http headers for the show_bug.cgi page help?
Comment 17 Matt Tyson 2012-10-21 19:10:15 EDT
Upstream have introduced a workaround for this in bugzilla 4.4, and will be fixed when Red Hat bugzilla is upgraded to 4.4.


This change is fairly invasive and won't be backported to 4.2

In the meantime I would recommend you use one of the workarounds detailed in comment 8.
Comment 18 Jan Pokorný 2012-10-22 06:24:52 EDT
Re [comment 13]:
I like the idea, it could prevent [bug 553189] type of issues as well.
Comment 19 Michal Novotny 2012-10-23 10:07:33 EDT
Hi all,
I've been communicating this with a guy from Mozilla and there's a great extension for this:


Comment 20 Matt Tyson 2012-10-24 19:48:34 EDT
(In reply to comment #19)
> Hi all,
> I've been communicating this with a guy from Mozilla and there's a great
> extension for this:
> https://addons.mozilla.org/en-US/firefox/addon/reload-plus/?src=search
> Michal

This looks like a good way to fix the problem.
In the plugin preferences screen
Left Mouse (or FKey) -> Override Cache.

This makes the hard refresh the default refresh when you hit F5 or the reload button.

This pretty much fixes the problem (so long as everyone involved uses it)

One thing to be aware of is that all form fields will be cleared. If you are used to firefox preserving comments then you may want to copy paste them across reloads.

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