Editing bugs loaded through history is all kinds of broken

RESOLVED FIXED

Status

()

--
major
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: bzbarsky, Unassigned)

Tracking

Details

BUILD: Current trunk or 3.6, whichever you prefer

STEPS TO REPRODUCE:
1)  Load an open bug of your choice (say this one).
2)  Focus the url bar.
3)  Type mozilla.org and hit enter.  Wait for the page to load.
4)  Click the back button.
5)  Try to resolve the bug as fixed

EXPECTED RESULTS: When "RESOLVED" is selected as the status, a new dropdown appears for the resolution.

ACTUAL RESULTS: New dropdown doesn't appear.

Additional information:  Clicking the "Mark as Duplicate" button doesn't change the resolution or cause the dropdown to appear.  Clicking the "take" or "edit" links next to the assignee and QA fields or the CC list does nothing.

This is a recent regression (last few days), and it's making Bugzilla incredibly painful to use....
Confirmed that this occurs on Firefox 3.6 and the latest 4.0, so is unlikely to  be a Firefox change. And I can confirm it does not happen on the landfill installs of the 3.6 and 4.0 branches, so it's likely to be a local customization.

However, there also seem to be no errors on the JS console.

Gev
We last updated on the 25th, to rev 7237. Someone with better bzr-fu than me will have to tell me when the last time was before that.

Gerv
Fairly sure this is just a caching issue... If you shift-reload, everything starts to work. Probably due to some js/field.js changes made.
Hmm...  Indeed, shift-reloading fixes.

Have we consdered sending max-age cache-control headers or Expires headers on the bugzilla js to avoid this issue?  Having it revalidate once a day, say, should not be a huge burden and would avoid the problem persisting for days or weeks (or until the user files a bug).
(In reply to comment #4)
> Have we consdered sending max-age cache-control headers or Expires headers on
> the bugzilla js to avoid this issue?  Having it revalidate once a day, say,
> should not be a huge burden and would avoid the problem persisting for days or
> weeks (or until the user files a bug).

Yep, all fixed by bug 428313 for Bugzilla 4.0.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
I'm reopening this, after putting up with it for several more days and thinking it's just my cache being weird.

Shift reloading does not in fact fix if you test following the steps in comment 0 _after_ you shift-reload; I tested incorrectly in comment 4.  Furthermore, I just tried clearing my cache and the problem is present.

Oh, and I tried a clean profile, and the problem is present.  So unless you think there's a cache between me and bugzilla somewhere, I think it's clear that caching is NOT the problem.

Now can we please fix this?  This is making using bugzilla pretty hellish.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to comment #2)
> We last updated on the 25th, to rev 7237. Someone with better bzr-fu than me
> will have to tell me when the last time was before that.

https://bugzilla.mozilla.org/cvs-update.log

(yeah, I never got around to renaming it when we stopped using cvs).

CCing a few people who might be able to give us an idea what's going on.
So for what it's worth, the symptoms make it look like beforeunload or pagehide removes some sort of listeners from somewhere.... and then pageshow doesn't restore them.
Looks like this was bug 607675 upstream (which is why you can't reproduce on landfill, because they already fixed it).  Reed just backported the patch to bmo.
Depends on: 607675
And it's been pushed to production.  Can you check if that fixed? (might have to shift+reload)
Yeah, now things look good.  Thanks!
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.