I hit this behavior while investigating a different issue. A button inside a XUL frame changes the src attribute of this frame to "about:blank" - and the browser chrome simply disappears, you have no choice but to press Alt-F4. According to DOM Inspector, the inner size of the browser window is 1280x744 and outer size is 1280x639 (yes, outer size is actually smaller than inner size). Only outer size changes when clicking the button, the original value is 1288x778. I am filing it under layout because that's my best guess but I have trouble imagining what causes this behavior. Testcase is attached, you simply have to click the button to reproduce. I see this behavior in Gecko/2007122005 Minefield/3.0b3pre started in safe mode on Windows XP, Firefox 2.0.0.11 however has no trouble whatsoever with the testcase.

Maybe related to bug 405472?

Yes, probably caused by the same bug (document going away while click event is being handled?) - but the problem in the testcase here is 100% reproducible.

I can't reproduce on Windows XP. Tried first with the 12/19 build I had and then the same 12/20 build you cite, with and without -safe-mode. When do you think this regressed for you?

I only mentioned -safe-mode because I have some extensions installed. Now I tried starting with a clean profile - the problem is still reproducible. Regression range is 2007092005 to 2007092105.

Looking at bonsai, bug 396587 is my prime suspect to have caused this behavior. Other possibilities are bug 396099, bug 389636 and nsGenericElement.cpp revision 3.596 (checked in with wrong bug number).

Baking out bug 396587 (manually, because the patch no longer applies) did not fix this. Baking out bug 396099 fixed it however. Just to be sure I patched bug 396099 back in and the same behavior came back.

This really feels like a Windows widgetry bug (given that I don't see this on Mac and the other two ways to reproduce this in the bugs this blocks). If needed we can try backing out bug 396099, but it seems like a much better idea to fix the real issue, since there are likely other ways to get this to happen... roc, ere, any idea what might be going on here?

I don't know layout well enough to say how it happens, but SyncFrameViewGeometryDependentProperties in nsContainerFrame.cpp calls nsWindow::SetHasTransparentBackground(true) setting the chrome translucent, and the chrome in question happens to be the browser window.. To me it seems that widget layer just does what's been told to it, but the content is getting a bit too much power here.

Yikes, it looks like we're doing a reflow at a pretty bad time there! Perhaps nsDocumentViewer::SetTextZoom/SetFullZoom should pass NS_VMREFRESH_DEFERRED instead of NO_SYNC? But we should figure out the root cause here anyway. I guess I can take it...

Sounds like basically bug 322074, then? See analysis there.

fixed by bug 322074

Confirmed, this is fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011005 Minefield/3.0b3pre.

verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3 and also per comment #12 no crash on testcase -> Verified fixed