The check in the WM_WINDOWPOSCHANGED handler doesn't correctly check for minimized windows. As far as I could tell, it's been broken for a while. This prevents us from being able to draw taskbar previews while windows are minimized.

(In reply to comment #0) > Created an attachment (id=387062) [details] > v1.0 > > The check in the WM_WINDOWPOSCHANGED handler doesn't correctly check for > minimized windows. As far as I could tell, it's been broken for a while. This > prevents us from being able to draw taskbar previews while windows are > minimized. Hmm, when would newWidth and newHeight both be zero with a top level that isn't iconic? I guess I'm curious why this is getting in the way of your preview rendering.

I'm not sure...I wonder if we could just get away with ::IsIconic(topLevelWnd). The hack seems to be introduced here in bug 56156 comment 33 with no good reason behind it.

(In reply to comment #2) > I'm not sure...I wonder if we could just get away with ::IsIconic(topLevelWnd). > The hack seems to be introduced here in bug 56156 comment 33 with no good > reason behind it. So was reflow to a 0x0 window still happening on some children, even though bug 56156 was supposed to fix that problem? IsIconic might not be true before the poschanged message is sent to children. What was the problem you were seeing in your preview rendering without this applied? I'm just curious about what you were seeing.

The problem I saw is that the nsIDOMWindow for the browser window had width and height = 0 which made it impossible to correctly draw a preview for it. Not sure about the message ordering. I should investigate that further (Windows doesn't provide good guarantees about message ordering).

(In reply to comment #4) > The problem I saw is that the nsIDOMWindow for the browser window had width and > height = 0 which made it impossible to correctly draw a preview for it. Not > sure about the message ordering. I should investigate that further (Windows > doesn't provide good guarantees about message ordering). Any chance we're going to get some sort of a performance hit or maybe even a performance gain by not letting these child windows go to 0x0?

I think there should be a gain but we don't have any test coverage on this. I'll run this through the try servers when they're less busy to see if we regressed any expected behavior (I hope not!). Maybe someone with more experience in layout can shed some light.

Yeah, I'd expect a performance gain since we wouldn't do all the work resizing all the content inside the window. It would also make us match other platforms, which is important.

(In reply to comment #1) > Hmm, when would newWidth and newHeight both be zero with a top level that isn't > iconic? I guess I'm curious why this is getting in the way of your preview > rendering. Well, newWidth and newHeight aren't for the toplevel window. For what it's worth, we do care about some 0x0 resizes... when they're done for windows inside Web content (see bug 448132). (In reply to comment #2) > I'm not sure...I wonder if we could just get away with ::IsIconic(topLevelWnd). > The hack seems to be introduced here in bug 56156 comment 33 with no good > reason behind it. I think it would be better than this patch, which I think would regress bug 448132. I also suspect the media queries test in acid3 fails while the window is minimized, with pretty much all options considered so far.

It turns out that we haven't been passing Acid 3's test #46 while the browser window is minimized. This patch suppresses the resize-due-to-minimize at the top level window which appears to suppress the child windows from getting any resize events. Firefox passes test #46 while minimized with this patch.

Pushed to mozilla-central: http://hg.mozilla.org/mozilla-central/rev/04cd5874f917