Red Hat Bugzilla – Bug 838095
Cached flags override expected settings
Last modified: 2012-10-24 19:48:34 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.
Steps to Reproduce:
Flags are cached.
Flags set properly.
*** Bug 835930 has been marked as a duplicate of this bug. ***
*** Bug 846402 has been marked as a duplicate of this bug. ***
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).
*** Bug 848668 has been marked as a duplicate of this bug. ***
*** Bug 850922 has been marked as a duplicate of this bug. ***
(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?
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.
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 )
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)
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.
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.
I'm seeing this issue since the big Bugzilla update that happened sometime ago.
Remember search and form history is disabled for me.
This is bad and is a bug in firefox in my opinion.
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.
(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.
Happens all the time on https://bugzilla.redhat.com/show_bug.cgi?id=829427.
Would emitting cache-disabling http headers for the show_bug.cgi page help?
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.
Re [comment 13]:
I like the idea, it could prevent [bug 553189] type of issues as well.
I've been communicating this with a guy from Mozilla and there's a great extension for this:
(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:
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.