it quickly redraws a glass frame. Not sure what's going on.

This bug report is fairly vague, but on my system at work the graphics card is slow enough that I can tell the window is being opened on one screen in some weird UI, then resized on my second monitor's desktop, then removed from my first display. This is a change from the last Mozilla Developer Preview -> 4.0b1

Anybody want to set this to blocking final?

(In reply to comment #1) > This bug report is fairly vague, but on my system at work the graphics card is > slow enough that I can tell the window is being opened on one screen in some > weird UI, then resized on my second monitor's desktop, then removed from my > first display. This is a change from the last Mozilla Developer Preview -> > 4.0b1 This should be fixed.(In reply to comment #2) > Anybody want to set this to blocking final? I don't think the original bug blocks, it's pretty minor IMHO.

(In reply to comment #3) > This should be fixed.(In reply to comment #2) Excellent. Is this for 4.0 release? > > Anybody want to set this to blocking final? > > I don't think the original bug blocks, it's pretty minor IMHO. I'm not sure what 'blocks' means in this context, but I will assume it means the blocking of 4.0 until the bug is fixed? Personally I find it a major bug on low-end systems since graphics cards with low performance or memory cause the system to take half a second to draw/resize the window. At work adding this up over the entire day means a lot of time wasted and a lot of irritation. We all have our pet peeves though so I can understand prioritizing more important bugs.

(In reply to comment #4) > (In reply to comment #3) > > This should be fixed.(In reply to comment #2) > > Excellent. Is this for 4.0 release? > > > > Anybody want to set this to blocking final? > > > > I don't think the original bug blocks, it's pretty minor IMHO. > > I'm not sure what 'blocks' means in this context, but I will assume it means > the blocking of 4.0 until the bug is fixed? Personally I find it a major bug on > low-end systems since graphics cards with low performance or memory cause the > system to take half a second to draw/resize the window. At work adding this up > over the entire day means a lot of time wasted and a lot of irritation. If you could snap a screen shot of what you're seeing that would be helpful. Even if the aero basic frame didn't show, how would this effect time wasted in redrawing the window? If resizing & drawing performance is an issue on slower systems, that's a different bug.

Initial shot at fixing this. Parts of the frame gets painted during the change to styles in HideWindowChrome via MakeFullscreen. style = tempStyle & ~(WS_CAPTION | WS_THICKFRAME); exStyle = tempExStyle & ~(WS_EX_DLGMODALFRAME | WS_EX_WINDOWEDGE | WS_EX_CLIENTEDGE | WS_EX_STATICEDGE); I'm still curious though why windows does this. This path suppresses the update. Also, there's a secondary bug in this. We update the glass margins during the initial stage of reflow for the resize, before content gets painted. Windows however updates the glass on the original normalized window immediately. So what we see is a normalized window where the glass briefly turns to black, then we repaint as a full screen window. It would be nice if we could find a way to prevent this, it's pretty ugly. I'll probably file off another bug on that though since it's not related to the issue described in this bug.

Comment on attachment 472187 [details] [diff] [review] patch v.1 This looks great in release builds. The transition is much smoother.

backed out due to regression on themed desktops. (bug 594773) http://hg.mozilla.org/mozilla-central/rev/ce4dbcbc75a2

Just a slight variation - restricting these change to glass desktops. A few side notes - this is present in 3.6, and also ie. We probably dont' need to block on this if we find other issues. I did a little additional experimenting around with handling the wm_nccalcsize event to try and prevent windows from preserving the main window on the resize, but ran into a bunch of problems. I think I'll spin that out into another bug.

Note this code was removed in bug 634586.