This is a regression between bug 2006-06-27-04-trunk and 2006-06-29-04-trunk Linux Firefox nightlies. See bug 333050 comment 19. I'm not sure the behavior is bad, but it seems to have changed unintentionally, so Boris and I are concerned that something may be broken. Steps to reproduce: 1. load http://tinderbox.mozilla.org/Firefox/ 2. click on somebody's name on the left side 3. in the popup that appears, click on "Check-ins within 24 hours" Actual results: 3. popup goes away significanly before bonsai query appears Expected results: 3. popup stays around until the bonsai query appears Note that this did make bug 333050 no longer be present, although it may just be covering it up in a specific case.

It'd be great to have a smaller regression range here...

I saw this behavior once with 2006-06-29-08-trunk and haven't seen it again. I've also seen the "spinning" after going back to the tbox page as described in comment 19 and crashed once (a different stack than what's in bug 333050, so perhaps a different bug).

I don't see any builds in that regression range, but maybe I'm missing something. Maybe Ria has some builds in that time frame.

Seems to have happened between 1.9a1_2006062715 and 1.9a1_2006062723.

Checkins: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=20060627+15&maxdate=20060627+23&cvsroot=%2Fcvsroot None look all that likely. I guess it could be a weird interaction with bug 58724 (if DOMContentLoaded fires before paint suppression is done and then we do something that somehow makes that popup go away?) or less likely bug 332730. The rest look even more unrelated. Does someone have time to try some local backouts?

I've backed out the patch for bug 332730 and I don't see the bug go away. I don't think I see the bug in 2006-06-30 trunk build of Seamonkey, so I guess that could mean this is indeed a regression from bug 58724 somehow.

The patch for bug 58724 was moved to bug 221634.

This happens because the password manager's unload event handler suddenly got working (which I think is a good thing), see bug 343282, comment 5. Probably, bug 343282 will be fixed with a patch that removes that unload event handler.

See testcase, adding any unload event handler to a document seems to cause the "disappearing frame content just before the page" issue. So this is more or less a more generic issue, although the tinderbox problem should be solved once bug 343282 is fixed.

Ah, so disabling bfcache also makes the popups go away before the page fully unloads? Is that true in older builds too?

(In reply to comment #10) > Ah, so disabling bfcache also makes the popups go away before the page fully > unloads? Is that true in older builds too? Yes, you're right. I've tried with a 2006-06-27 trunk build and set browser.sessionhistory.max_total_viewers to 0. After that I can see this bug. So before bfcache existed, this bug was already there.

Do you actually see the bug with a pre-bfcache build?

(In reply to comment #12) > Do you actually see the bug with a pre-bfcache build? Yes, tested also with Mozilla1.7.12.

Fixed by bug 343282.

Ok, this is fixed. Do we want to have a new bug on the underlying issue (in the case where bfcache isn't preventing this bug from happening)?

Might be worth it, or at least minimizing a testcase for it...

Ok, I filed bug 345026.