Fix a whole category of frame switching bugs relating to the window z-order being screwed up screwed up when DWM is toggled or themes are installed or reset.

The first part of the fix was to remove the hack I put in to hide then show the window while the frame type change occurs.

The hack was to work around the fact that upon returning to glass from non-glass, the area identified by BrowserFrameWin::OnNCCalcSize as client was filled with solid black vs. transparent black.

I don't know why this fix works, but returning a client size for the opaque frame as 1 pixel different to the window rect causes the blackness bug to not occur, so that's what I did (in addition to removing the hack).

I also had to put in a couple of fixes to accommodate the pixel turd we gain in the opaque frame. I renamed ChangeSize to LayoutRootView. When we're using the opaque frame, since the views system is rendering the entire content of the window all the time I always size the widget to the window rect rather than the client rect.

http://crbug.com/15424
TEST=change the frame type by:

- turning on/off aero glass
- installing a theme, then resetting
- running an app that forces the DWM off, e.g. the O3D plugin

The frame should appear correct after the transition in either direction, and window z-order should be preserved.

Review URL: http://codereview.chromium.org/266013

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29164 0039d316-1c4b-4281-b951-d872f2087c98
5 files changed