Chrome has a long-standing bug due to the design of its frames where when you toggle DWM on and off on Vista the app is rendered unusable due to the top area of the browser window being rendered black. This is because the display mode it was using is suddenly changed out from under it and some assumptions that exist no longer hold true.
With MagicBrowzr, the theory was we could solve this by allowing the content of the BrowserView to be re-parented into a new window of the correct frame type when the DWM is toggled. With some experimentation though it's become clear this is slightly problematic: - lots of views assume they're only inserted into a view hierarchy once, and thus re-run init code when this happens which sometimes has harmful effects - there is an undesirable animation as the DWM replacement window is opened/closed With some thought, I've come to thinking that having a separate class for the custom frame window from the regular non-custom frame window is problematic, because this is the only reason we need to swap frames. I am thinking it might be better to coalesce these two types, since one is a strict subset of another, and just have a mode on the object that indicates it's using a custom frame. Then when we switch DWM off we can toggle the mode and avoid some of these gymnastics. -Ben --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
