629670 - Editing bugs loaded through history is all kinds of broken

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: General, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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....

Comment 1

[Gervase Markham [:gerv]]

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

Comment 2

[Gervase Markham [:gerv]]

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

Comment 3

[Reed Loden [:reed]]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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).

Comment 5

[Reed Loden [:reed]]

(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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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.

Comment 7

[Dave Miller [:justdave]]

(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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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.

Comment 9

[Dave Miller [:justdave]]

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.

Comment 10

[Dave Miller [:justdave]]

And it's been pushed to production.  Can you check if that fixed? (might have to shift+reload)

Comment 11

[Boris Zbarsky [:bzbarsky]]

Yeah, now things look good.  Thanks!