Glen, where in the code did you do that fix for vista? Could we revert that?

The Vista change was pre-MagicBrowzr, not sure how it carried over to Magic Browzr. 
At the time it was Aero frame only.

Is there _any_ way to just enable that for Windows Vista? Should I check if its 
Windows Vista and use that magic browser else disable it

Magic BrowzR is "frame code version 2".  I think the old frames are gone at this 
point.  You can't (and wouldn't want to) disable it.

We simply need to fix this.

I think you might be misunderstanding the bug report - Peter was just saying that the 
bug appears similar to this thing we did long ago for Vista that is no-longer valid, 
so that may be a clue as to the cause, rather than being the cause.

If you wanted to investigate, maybe look at the code calling IsMaximized in 
opaque_non_client_view. Probably in the OpaqueNonClientView::Layout* methods.

That explains why the frames are shown like this:
http://i36.tinypic.com/ddlyyh.jpg

Notice the title bar (windows XP)

No, that is an entirely different bug from this.  Talk to Ben about that.

Glen,
I am really new to windows c++ ui, but when I look at the Layout* methods, the y 
coordinates for all the bounds is 0. So how can that explain why the buttons 
(max,min,restore) are going negative ? Negative in a way that is seemed to be moved 
up about 3 px

Okay, Ben explained me what was going on irc.

When a window becomes maximized, Windows resizes the window to be slightly larger 
than the screen by the width of the window borders on each edge. This is apparently 
so apps don't need to adjust their rendering when being maximized.

However, the border size on Windows XP and Windows Vista are different with glass 
turned off. And on Windows Vista, you can adjust the value within the control panel.

And there appears to be no way query for this value on each platform. "yet"

Back to plan 1

This is from XP too.

http://www.google.com/support/forum/p/Chrome/thread?tid=38ccb8f4eb1d17ba&hl=en

Yes we know

(No comment was entered for this change.)

I am trying to re investigate this, can someone please answer these questions. But 
before I say the questions, I want to make sure I am on the same page.

If you have two monitors, you can see what is going on. In my scenario, I have 
monitor, | A | B | In that order.

If we maximize the first monitor, you can see the right edge of it in Monitor B. A 
Black thin line (as you see in normal_state_left_monitor_maximize_screen.png ) If you 
maximize it on my smaller monitor (right) you will see same thing ( normal_state_right_monitor_maximize_screen.png )

Okay now my questions.

1) According to opaque_non_client_view, why can't this be fixed correctly? They are 
dependent on the variables we set (kWindowTopMarginZoomed, kTitleTopOffset, kTitleBottomSpacing, kWindowHorizontalBorderSize, kWindowVerticalBorderTopSize, kWindowVerticalBorderBottomSize) Why can't we fix those variables to make it work for 
Windows XP? I thought opaque_non_client_view is for Windows XP and aero_glass_frame 
is for Windows Vista, or am I mistaken?  If I am wrong I assume if they have aero 
glass theme they would use that class, otherwise use the opaque.

Then for Windows Vista, we can get the current frame border padding and use that to 
make sure Maximize works. What am I interpreting incorrect?

The way I would fix this is:
a) Make it render good in Windows XP, by adjusting those values (or I am looking at 
the wrong place?)
b) Check if windows vista is present and then check the border padding size
c) Apply that border padding to make sure Maximize works fine.

I assume these screen shots work on Windows Vista default settings if they didn't 
change the border padding offset in Control Panel.

If anyone could clarify these, I could do this.

	normal_state_screen.png 136 KB   View   Download

	normal_state_left_monitor_maximize_screen.png 165 KB   View   Download

	normal_state_right_monitor_maximize_screen.png 149 KB   View   Download

I'm working on this.

Alright, then some tips that can help you solve the Windows Vista Aero border size 
since its dynamic.

You could use DwmGetWindowAttribute in dwmapi.dll. Two calls could be used, first 
with DWMWA_NCRENDERING_ENABLED which determines the non-client rendering. Then if 
that returns true, you  then call with DWMWA_EXTENDED_FRAME_BOUNDS which gets the 
extended bounds rectangle in the screen.

I hope that will help solve the issue that you guys are having.

Is that Aero-only?  We don't have issues with Aero mode because we let the OS draw 
our frame.  Our only problems are in non-Aero mode.  I believe users can still change 
the frame size in non-Aero mode, I don't know what calls check that size though.

No, afaik, it is for all desktop window modes. This simply tells you what size it is. 
Maybe you don't need to check DWMWA_NCRENDERING_ENABLED, have to check. I will 
install windows vista on one of my machines right now.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=7391 

------------------------------------------------------------------------
r7391 | pkasting@chromium.org | 2008-12-22 15:18:37 -0800 (Mon, 22 Dec 2008) | 13 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.cc?r1=7391&r2=7390

Make Maximized Mode Not Suck, part 1 (checkpoint).

Pixel perfection (I think) on Normal and App windows, maximized and restored, on Windows XP Luna with default fonts and border widths.  Among other things, fixes window control placement, tabstrip height, window icon/title placement, and client edge drawing (especially at the tops/bottoms of windows).

Known to still be broken: Popup windows
Untested: Vista non-Aero, Classic, non-default fonts/borders, non-main windows (Options, Task Manager, etc.)

This change is pretty hacky in some places; once I get the behavior nailed perfectly I'll need to go back and try and cut down on the number of constants and use better logic instead.  I do at least try to remove some of the current hacks or else document them.

Eventually I'll need Ben's and Glen's eyeballs for things, as I've had to make judgment calls about the correct behaviors; some of these I copied our 1.0 behavior, and some I've tried to ape a native app more closely.  Especially tricky are the positioning of window icons/titles, since our titlebar isn't quite like a native one.

BUG=5054
Review URL: http://codereview.chromium.org/16219
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=7908 

------------------------------------------------------------------------
r7908 | pkasting@chromium.org | 2009-01-12 16:55:40 -0800 (Mon, 12 Jan 2009) | 12 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.cc?r1=7908&r2=7907
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.h?r1=7908&r2=7907

Pixel perfection on OTR icon.  The tabstrip is still positioned/sized wrong relative to the OTR icon, sadly.

Much of the issue here is because the OTR image was a child view in the old code and isn't in the new.  As a result, we have to:
* Change the drawing order to draw the OTR image after the tabstrip (like a child view would normally have been drawn), so the tabstrip's semi-transparent pixels don't overlay it
* Change the bounds calculation and drawing code to clip the image properly in maximized mode (where a child view would have been clipped naturally)

Since I changed the calling order of the OTR functions, I also changed their declaration/definition order to follow suit.

This also tries to rename a few constants to be more consistent.  I can't figure out how to make any of these read nicely :(

BUG=5054
Review URL: http://codereview.chromium.org/17362
------------------------------------------------------------------------

 Issue 6362  has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=7976 

------------------------------------------------------------------------
r7976 | pkasting@chromium.org | 2009-01-13 14:34:48 -0800 (Tue, 13 Jan 2009) | 2 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/aero_glass_non_client_view.h?r1=7976&r2=7975
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/browser_frame.h?r1=7976&r2=7975
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/browser_view.cc?r1=7976&r2=7975
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.cc?r1=7976&r2=7975
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.h?r1=7976&r2=7975

Pixel perfection on tabstrip for non-Aero frame.  This gets both ends of the tabstrip positioned correctly for normal and incognito windows, in both restored and maximized modes.The chief change was to correctly transform the bounds returned by the non-client view into the BrowserView's coordinate system, as the Views system expected.  To make this not break the world I then had to actually return the right coordinates in the non-client view :).  Updated comments on function declarations to hopefully match reality.For convenience this also introduces a function to get the horizontal border size and cleans up existing code to use it.BUG=5054
Review URL: http://codereview.chromium.org/18019
------------------------------------------------------------------------

The bugdroid hasn't quite caught up yet, but as of now, the status is (in the order I 
intend to tackle these):
* Normal, incognito, and app windows, as well as the status bubble, should be pixel-
perfect on Classic and Luna with any window border size.  Yay!
* Non-default titlebar fonts are untested.
* The code is still gross and needs major cleanup.  I've been worrying more about 
correct behavior than clean logic.
* The bookmark manager window is still broken in maximized mode.
* Popup windows still have a janky-looking address bar.
* Vista non-Aero is untested.  In theory it should be similar to Classic/Luna, though 
I worry that window borders may not be quite the same in all cases on Vista.
* Vista Aero has not been touched at all yet (and is thus still completely broken).

pkasting, get the attribute DWMWA_EXTENDED_FRAME_BOUNDS  from calling DwmGetWindowAttribute as I explained earlier, that will allow you to know the "real" 
size of the window borders on "all" cases on Vista.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=8059 

------------------------------------------------------------------------
r8059 | pkasting@chromium.org | 2009-01-14 17:05:11 -0800 (Wed, 14 Jan 2009) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/browser_view.cc?r1=8059&r2=8058

Fix status bubble positioning with custom border widths by positioning the bubble relative to the client area and then converting to parent coordinates instead of trying to position it absolutely with hardcoded constants.

Also changes an Offset() call to ConvertPointToView(), which is functionally the same but I think clearer in intent.

BUG=5054

TEST=In both Classic and Luna, use the Display control panel to set your active/inactive border widths to something nonstandard (try 20, that's real noticeable) and maximize a Chrome window. Make sure when hovering a link that the status bubble appears aligned with the screen corner instead of partly offscreen.
Review URL: http://codereview.chromium.org/18253
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=8060 

------------------------------------------------------------------------
r8060 | pkasting@chromium.org | 2009-01-14 17:09:58 -0800 (Wed, 14 Jan 2009) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.cc?r1=8060&r2=8059
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.h?r1=8060&r2=8059

Render maximized mode better when using nonstandard border widths.

This change is a bit gross.  It calls out to GetSystemMetrics() all over this code, which just shows how many places are sizing themselves from the window edge instead of from the window border edge.  When cleaning this file up to be more sane, I intend to make most of these functions position themselves based on the border edge, which should cut down the number of these calls to just a couple (and perhaps collapse some of the constants together too).

BUG=5054

TEST=In both Classic and Luna, use the Display control panel to set your active/inactive border widths to something nonstandard (try 20, that's real noticeable) and maximize a Chrome window.  Make sure the window controls appear where you expect instead of partly or totally off the screen edges.
Review URL: http://codereview.chromium.org/18255
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=8062 

------------------------------------------------------------------------
r8062 | pkasting@chromium.org | 2009-01-14 17:14:30 -0800 (Wed, 14 Jan 2009) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/custom_frame_window.cc?r1=8062&r2=8061

Fix maximized mode drawing offscreen in Classic mode.  Apparently Classic, unlike Luna, does not auto-clip maximized windows with an explicitly-set HRGN of NULL, so we have to set one.

BUG=5054

TEST=On a desktop extended across multiple monitors, switch to Classic mode, open a Chrome window, and maximize it on one monitor.  Make sure it doesn't draw any pixels on the other monitor.
Review URL: http://codereview.chromium.org/18258
------------------------------------------------------------------------

 Issue 4876  has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=8348 

------------------------------------------------------------------------
r8348 | pkasting@chromium.org | 2009-01-20 17:05:25 -0800 (Tue, 20 Jan 2009) | 4 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tab_icon_view.cc?r1=8348&r2=8347
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tab_icon_view.h?r1=8348&r2=8347
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_renderer.cc?r1=8348&r2=8347
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/gfx/chrome_canvas.cc?r1=8348&r2=8347

Fix some problems with scaled icons.  This allows the TabIconView to automatically scale the throbber and favicon to whatever size the View itself is.  Notably, this does NOT change tab_renderer.cc, which _also_ draws favicons -- the former is used by app windows and the latter by standard tabs.  Argh!  I'm not going to bother unifying these for now even though it'd be nice, since we never scale up our tabs, just our app titlebars.

BUG=5054
Review URL: http://codereview.chromium.org/18392
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=8349 

------------------------------------------------------------------------
r8349 | pkasting@chromium.org | 2009-01-20 17:05:39 -0800 (Tue, 20 Jan 2009) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.cc?r1=8349&r2=8348

Correct icon/title sizing/placement for varying titlebar font sizes.  This matches Windows pixel-for-pixel except where we adjust things slightly in restored mode to look better with our frame shape, and in occasional cases where our scaling differs slightly, mainly because the Windows icon caching makes it almost impossible to tell what the "correct" Windows behavior actually is.

This depends on my oustanding "fix scaled icon problems" change.

BUG=5054
Review URL: http://codereview.chromium.org/18396
------------------------------------------------------------------------

(No comment was entered for this change.)

I believe this is fixed.

Please don't close bugs I'm in the middle of working on (thought this was clear from 
my comments above).

In 2.0.158.0 it only became worse: the space between the edge of the screen and the 
edge of chrome became bigger. (Screenshot attached)

Nieuwe bitmapafbeelding.bmp 3.8 MB   Download

*Yuck* Vista, single screen, and now the tabs are hiding 20% off the screen (tabs too 
high)

I don't know why it's so unclear that _Vista hasn't been touched yet_.  That's 
precisely why this bug isn't closed.  There's a lot of work still to do.  Please stop 
adding noise.

Then I will try to add something meaningful.

This problem may be caused by Chrome assuming that Border Padding is 5px with Aero 
Glass, although this value can be changed by the user to any value they want.  As a 
result when the value is, say, 0, Chrome leaves 5px edge around the client area that 
is not drawn.

 Issue 6926  has been merged into this issue.

 Issue 6989  has been merged into this issue.

 Issue 6964  has been merged into this issue.

 Issue 6938  has been merged into this issue.

This is a reply for comment 36:

You are partly right, I have Windows Vista and use Chrome 2.0.158.0.
I use 1 pixel window border settings in Vista Aero and have the problem.
When I set the window border settings to 5 pixels the frame is drawn okey, but the 
tubs are still getting cut and appears to be in the negative.  

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=8658 

------------------------------------------------------------------------
r8658 | pkasting@chromium.org | 2009-01-26 12:28:25 -0800 (Mon, 26 Jan 2009) | 14 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/constrained_window_impl.cc?r1=8658&r2=8657
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.cc?r1=8658&r2=8657
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.h?r1=8658&r2=8657
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/gfx/chrome_canvas.cc?r1=8658&r2=8657
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/gfx/chrome_canvas.h?r1=8658&r2=8657
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/custom_frame_window.cc?r1=8658&r2=8657
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/non_client_view.cc?r1=8658&r2=8657
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/non_client_view.h?r1=8658&r2=8657

This change should have few user-visible effects.  I think I slightly modified the window layout (by a pixel or so) in the popup window case, which I haven't tried to make pixel-perfect yet anyway.  Otherwise it's all reorg.

Clean up logic of nonclient view to be more consistent and coherent.  Most things are now based on a small set of core functions that return various frame/nonclient thicknesses.  This allows a noticeable reduction in the number of hardcoded constants, makes the code make more sense (even though a few places are longer than before), and makes it much easier to do things in the future like resizing various borders or handling system metrics better.

Rename and update comments for all constants to be more descriptive and less redundant.

Rename helper functions and variables for consistency, now that they've changed.

Remove an unused variant of TileImageInt().  Add a new one that takes an offset into the source image.  This is used to rewrite the maximized bottom border tiling call in a way that doesn't rely on someone else clipping out or painting over the overdraw from tiling "too large" a source image.  Probably no visible effect.

Make resize border hittest helper function able to handle borders of varying widths, and try to make parameter names more meaningful.  Technically, we don't need the extra flexibility, since our bottom and side borders are the same thickness, but since there are different functions calculating that thickness on the caller side, it didn't hurt to not rely on that for the future.

BUG=5054
Review URL: http://codereview.chromium.org/18804
------------------------------------------------------------------------

Since the last update, non-default titlebar font sizes have been tested, found to be 
woefully lacking, and fixed; small bugs like incorrect window masks have been 
patched; and the code has been cleaned up significantly.

Next I intend to tackle popup windows, then dialogs.  After that things should be 
done as far as XP goes, and I can turn my attention to Vista.  The most egregious 
problems on Vista ought to be easy; there's a particular function where the caller is 
providing child coordinates but the callee expects parent coordinates, which results 
in things like tabs clipping off, too thick a frame, etc.  Fixing custom border 
widths will take more time but affects a lot fewer people.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=8726 

------------------------------------------------------------------------
r8726 | pkasting@chromium.org | 2009-01-27 09:58:51 -0800 (Tue, 27 Jan 2009) | 4 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/browser_view.cc?r1=8726&r2=8725
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/browser_view.h?r1=8726&r2=8725
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.cc?r1=8726&r2=8725
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.h?r1=8726&r2=8725
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/toolbar_view.cc?r1=8726&r2=8725
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/toolbar_view.h?r1=8726&r2=8725

Make popups closer to pixel-perfect.  The main problem is that the toolbar is constrained to the width of the client area, when it actually needs to extend out two pixesl on each side into the current nonclient area.  I don't have a good fix for this, hoping Ben comes up with a brilliant idea.

BUG=5054
Review URL: http://codereview.chromium.org/18799
------------------------------------------------------------------------

 Issue 7090  has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=8758 

------------------------------------------------------------------------
r8758 | pkasting@chromium.org | 2009-01-27 14:00:33 -0800 (Tue, 27 Jan 2009) | 4 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/toolbar_view.cc?r1=8758&r2=8757

Fix a small, subtle problem that caused an interactive_ui_test failure.

BUG=5054
Review URL: http://codereview.chromium.org/18865
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=8763 

------------------------------------------------------------------------
r8763 | pkasting@chromium.org | 2009-01-27 14:26:11 -0800 (Tue, 27 Jan 2009) | 4 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/theme/locationbg_readonly_left.png?r1=8763&r2=8762
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/theme/locationbg_readonly_right.png?r1=8763&r2=8762
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.cc?r1=8763&r2=8762
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/location_bar_view.cc?r1=8763&r2=8762

Extend the popup-mode location bar out into the nonclient view.  This makes popup mode pixel perfect except for the off-by-one sizing regression caught by the interactive UI test, which I haven't figured out yet.

BUG=5054
Review URL: http://codereview.chromium.org/18862
------------------------------------------------------------------------

 Issue 7133  has been merged into this issue.

 Issue 7134  has been merged into this issue.

top of tab being clipped off as reported in  issue 7090  still exists in

Chromium	2.0.160.0 (Developer Build 8949)
WebKit	530.0
V8	0.4.9.2
User Agent	Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/530.0 
(KHTML, like Gecko) Chrome/2.0.160.0 Safari/530.0

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=8947 

------------------------------------------------------------------------
r8947 | pkasting@chromium.org | 2009-01-29 18:36:54 -0800 (Thu, 29 Jan 2009) | 13 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/constrained_window_impl.cc?r1=8947&r2=8946
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/custom_frame_window.cc?r1=8947&r2=8946

Fix various problems with constrained windows and/or custom frame windows:
* Wrong titlebar height
* Titlebars not handling custom font size properly
* Drawing errors in maximized mode
* One-pixel overlap glitch on bottom corners of client edges
* Borders not handling custom border sizes correctly
* Unnecessarily small top resize area (unlike in the main window, there's no competition here between resizing and window dragging in the same small strip)
* Wrong icon sizing (only a problem in theory, no one uses this code ATM)

These files are now very much like simplified versions of the opaque_non_client_view.cc code (which was the goal); eventually all these should be refactorable.

BUG=5054
Review URL: http://codereview.chromium.org/19484
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=9009 

------------------------------------------------------------------------
r9009 | pkasting@chromium.org | 2009-01-30 18:22:13 -0800 (Fri, 30 Jan 2009) | 4 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/custom_frame_window.cc?r1=9009&r2=9008

Fix Aero Basic (i.e. non-glass) maximized mode drawing.  This old hack was interfering with my new code that should do things at least somewhat more correctly.

BUG=5054
Review URL: http://codereview.chromium.org/19728
------------------------------------------------------------------------

At this point popup windows and dialogs have been fixed, the bottom frame border has 
been removed, and Vista Aero Basic (NOT GLASS) has been fixed.  So, basically, three 
of the four NonClientView subclasses should be correct.

I will work on Aero Glass next, and once that's done, refactor all of these to share 
base code; the files I've touched so far have already been reorganized to be 
conducive to this.  I tried doing a hack-and-slash version of the Aero Glass changes 
but it just made things worse, so I'm going to need to go back and do it more 
carefully.

 Issue 7300  has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=9062 

------------------------------------------------------------------------
r9062 | pkasting@chromium.org | 2009-02-02 17:43:19 -0800 (Mon, 02 Feb 2009) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/aero_glass_frame.cc?r1=9062&r2=9061
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/aero_glass_non_client_view.cc?r1=9062&r2=9061

Fix some of the most egregious problems with Aero glass frames.  These changes are basically hacks, but they're hacks that get our frame width, tabstrip layout (in non-OTR mode), and client edge drawing to exactly match pre-Magic-BrowzR code.  In subsequent changes I will clean this all up to work better.

This also fixes windows refusing to become activated.

BUG=5054,6174
Review URL: http://codereview.chromium.org/19548
------------------------------------------------------------------------

The top of the tab looks much better (correct) in 

Chromium	2.0.160.0 (Developer Build 9065)
WebKit	530.0
V8	0.4.9.3
User Agent	Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/530.0 
(KHTML, like Gecko) Chrome/2.0.160.0 Safari/530.0

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=9116 

------------------------------------------------------------------------
r9116 | pkasting@chromium.org | 2009-02-03 17:02:00 -0800 (Tue, 03 Feb 2009) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/autocomplete/autocomplete_popup.cc?r1=9116&r2=9115
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/aero_glass_frame.cc?r1=9116&r2=9115
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/aero_glass_non_client_view.cc?r1=9116&r2=9115
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/browser_view.cc?r1=9116&r2=9115
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/location_bar_view.cc?r1=9116&r2=9115
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/location_bar_view.h?r1=9116&r2=9115
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/toolbar_view.cc?r1=9116&r2=9115
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/gfx/chrome_canvas.cc?r1=9116&r2=9115
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/gfx/chrome_canvas.h?r1=9116&r2=9115

Improved OTR avatar and popup window rendering.  Neither one precisely matches the old code but IMO each looks better.

Once again, the aero_glass_non_client_view changes here are hackish, and will get cleaned up later.

BUG=5054
Review URL: http://codereview.chromium.org/20011
------------------------------------------------------------------------

 Issue 7431  has been merged into this issue.

With my latest commit to this (not yet posted on here by the bugdroid), I believe all 
the user-visible issues are fixed, and all that remains is refactoring code, so I'm 
closing this.

 Issue 3603  has been merged into this issue.

 Issue 7309  has been merged into this issue.

 Issue 6587  has been merged into this issue.

 Issue 3595  has been merged into this issue.

 Issue 3732  has been merged into this issue.

 Issue 1015  has been merged into this issue.

 Issue 2488  has been merged into this issue.

 Issue 4373  has been merged into this issue.

 Issue 4673  has been merged into this issue.

 Issue 4914  has been merged into this issue.

 Issue 4903  has been merged into this issue.

 Issue 5065  has been merged into this issue.

 Issue 5224  has been merged into this issue.

 Issue 4303  has been merged into this issue.

 Issue 6184  has been merged into this issue.

 Issue 6265  has been merged into this issue.

 Issue 6454  has been merged into this issue.

 Issue 6948  has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=9315 

------------------------------------------------------------------------
r9315 | pkasting@chromium.org | 2009-02-06 09:33:14 -0800 (Fri, 06 Feb 2009) | 4 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/aero_glass_frame.cc?r1=9315&r2=9314
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/aero_glass_non_client_view.cc?r1=9315&r2=9314
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/non_client_view.cc?r1=9315&r2=9314

Support custom border widths.  Allow user to resize the window (instead of doing nothing) when over our client edge graphics.  Make resize corner behavior on XP more native.  More cleanup.

BUG=5054
Review URL: http://codereview.chromium.org/21116
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=9433 

------------------------------------------------------------------------
r9433 | pkasting@chromium.org | 2009-02-09 14:48:03 -0800 (Mon, 09 Feb 2009) | 4 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/constrained_window_impl.cc?r1=9433&r2=9432
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/aero_glass_frame.cc?r1=9433&r2=9432
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/aero_glass_frame.h?r1=9433&r2=9432
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/aero_glass_non_client_view.cc?r1=9433&r2=9432
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/aero_glass_non_client_view.h?r1=9433&r2=9432
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.cc?r1=9433&r2=9432
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/frame/opaque_non_client_view.h?r1=9433&r2=9432
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/custom_frame_window.cc?r1=9433&r2=9432
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/non_client_view.cc?r1=9433&r2=9432
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/views/non_client_view.h?r1=9433&r2=9432

Make aero glass code look more like other nonclient views in hopes of easing refactoring.  More cleanup.  Change tabstrip layout to match opaque frame.

BUG=5054
Review URL: http://codereview.chromium.org/20161
------------------------------------------------------------------------

 Issue 7010  has been merged into this issue.