409223 - Content can make browser chrome disappear

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Wladimir Palant]

Attachment: Testcase

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.

Comment 1

[Martijn Wargers (dead)]

Maybe related to bug 405472?

Comment 2

[Wladimir Palant]

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.

Comment 3

[Daniel Veditz [:dveditz]]

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?

Comment 4

[Wladimir Palant]

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.

Comment 5

[Wladimir Palant]

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

Comment 6

[Wladimir Palant]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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?

Comment 8

[Ere Maijala (slow)]

Attachment: Stack trace

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.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

fixed by bug 322074

Comment 12

[Wladimir Palant]

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

Comment 13

[Carsten Book [:Tomcat]]

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