Bug 838095

Summary: Cached flags override expected settings
Product: [Community] Bugzilla Reporter: Marek Goldmann <mgoldman>
Component: User InterfaceAssignee: Matt Tyson 🤬 <mtyson>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.2CC: cpelland, fche, gwync, jpokorny, kbaker, mclasen, minovotn, misty, mjw, mkletzan, mmaslano, rjones, syeghiay, tmraz, twoerner
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-10-21 23:10:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marek Goldmann 2012-07-06 14:24:17 UTC
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:

Always.

Steps to Reproduce:

See above.
  
Actual results:

Flags are cached.

Expected results:

Flags set properly.

Comment 1 Simon Green 2012-08-16 04:23:48 UTC
*** Bug 835930 has been marked as a duplicate of this bug. ***

Comment 2 Simon Green 2012-08-16 04:24:00 UTC
*** Bug 846402 has been marked as a duplicate of this bug. ***

Comment 3 Simon Green 2012-08-16 04:25:48 UTC
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-17 01:48:54 UTC
*** Bug 848668 has been marked as a duplicate of this bug. ***

Comment 5 Simon Green 2012-08-29 01:06:17 UTC
*** Bug 850922 has been marked as a duplicate of this bug. ***

Comment 6 Simon Green 2012-08-29 06:03:27 UTC
(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 Logcher 2012-08-29 21:00:14 UTC
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-30 01:09:42 UTC
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 16:15:58 UTC
Simon,

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.

Kev

Comment 10 Tomas Mraz 2012-10-10 15:59:09 UTC
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 16:47:46 UTC
I'm seeing this issue since the big Bugzilla update that happened sometime ago.

Comment 12 Thomas Woerner 2012-10-17 16:05:06 UTC
Remember search and form history is disabled for me. 

browser.formfill.enable: false

but

browser.formfill.saveHttpsForms: true

This is bad and is a bug in firefox in my opinion.

Comment 13 Martin Kletzander 2012-10-17 16:28:02 UTC
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 16:29:13 UTC
(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 17:16:20 UTC
Happens all the time on https://bugzilla.redhat.com/show_bug.cgi?id=829427.
Please fix.

Comment 16 Frank Ch. Eigler 2012-10-19 19:11:51 UTC
Would emitting cache-disabling http headers for the show_bug.cgi page help?

Comment 17 Matt Tyson 🤬 2012-10-21 23:10:15 UTC
Upstream have introduced a workaround for this in bugzilla 4.4, and will be fixed when Red Hat bugzilla is upgraded to 4.4.

https://bugzilla.mozilla.org/show_bug.cgi?id=437212

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ý [poki] 2012-10-22 10:24:52 UTC
Re [comment 13]:
I like the idea, it could prevent [bug 553189] type of issues as well.

Comment 19 Michal Novotny 2012-10-23 14:07:33 UTC
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

Comment 20 Matt Tyson 🤬 2012-10-24 23:48:34 UTC
(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.