Issue 26564  has been merged into this issue.

Ben says that at least right now, making the whole window client area on Aero causes 
black flashing.  We must be doing something Windows doesn't expect.

Area-UI-Features label replaces Area-BrowserUI label

(No comment was entered for this change.)

 Issue 35804  has been merged into this issue.

 Issue 9184  has been merged into this issue.

 Issue 56853  has been merged into this issue.

 Issue 59444  has been merged into this issue.

 Issue 63974  has been merged into this issue.

 Issue 46536  has been merged into this issue.

 Issue 65437  has been merged into this issue.

Issue 72550 has been merged into this issue.

I don't get how Google is sooo lazy to fix this minor annoyances... 

It's not laziness.  We've actually spent quite a lot of time researching this and no one has ever figured out a way to do it without side effects.

Then perhaps it is necessary to implement a fix, and then deal with the side-effects as a separate issue?

The poster of Comment 12 is correct - this has been successfully implemented in all the other browsers. I personally think its just plain silly that your drawing code is trying to maintain any of the non-client area. As far as I know, Office doesn't have a non-client area at all, nor does Firefox, etc. That would suggest it isn't necessary to keep it around at all, so why is it still here?
Admittedly, I haven't taken a look at your code-base so I don't know what you're working with currently, but according to http://www.codeproject.com/KB/dialog/AeroNonClientAreaButtons.aspx, implementing this should be trivial.

This was the first thing I noticed when I looked at Chrome's interface, and that was several versions ago. Please, can we fix it?

We welcome outside patches.  I would be happy to review your fix, even if it takes more than a week.

For anyone who's not writing an actual patch, please refrain from adding comments about how you'd like to see this fixed or how incompetent we are.  They may be true, but they don't help the bug progress.  Just star the bug.

Yep, we're quite familiar with that info -- it's a pretty basic overview of extending the DWM frame into the client area and/or removing the nonclient area.

Firefox uses non-standard border widths.

If you look at Firefox 4 you'll see that their border width is slightly wider than Chrome.

We actually started out doing the same thing but valued matching system metrics for border widths (which are customizable in the Control Panel) more than this visual glitch.

The reason is our visual style causes us to want to render our own client edge that differs from the one provided by the DWM. Trouble is the DWM renders this in the non client area. We only ever render into client area.

There is always room for improvement in our UI and windowing system however it's not always as simple as it may appear. Please check out src/views/widget and src/views/window to get a better idea of the amount of code needed to write a Windows application UI.

The amount of UI code in Chrome is on the order of the amount of WebKit code.  It's extremely non-trivial. :)

Mozilla has a different window frame design that uses the default DWM nonclient area around the side and bottom borders.  If you look at the side of a Firefox 4 window versus a Chrome window you will see that the Chrome window frame appears to be thinner and has a different shadow/groove appearance.  Unfortunately, Microsoft never considered that someone might want to _partially_ extend the client area sideways into the nonclient area, which is why our caption location is wrong.  This bug is about making the whole window client area, which ought to fix the caption button problem, but for some reason triggers the other problems we've mentioned.

It seems like there must be some way to get all this correct, but we haven't found it, and spending man-months of time to fix what in the end is a purely cosmetic flaw in the caption button position just isn't justifiable.  That's why, as I said above, we'd be happy to have outside help here.

That is something else about chrome that looks odd - the window frame.
 - Why is the window frame thinner than in standard Windows applications?
 - Why does chrome "want to be thinner" if that is what breaks things?

Isn't it chrome that is non-standard, not Firefox? Firefox appears to have the same window frame size as any standard Windows application and chrome appears to have a thinner window frame.

At least the last time I measured it, the number of pixels from the window edge to the content edge on Chrome exactly matches e.g. Wordpad.  It's been a while though.

@24 - They are same but Chrome has a white border and standard Windows applications has a black border. On a white website the frame looks thinner.

We do, in fact, look at the system border width and customize Chrome's appearance to match -- or at least we used to a year ago when I last touched that code.

This isn't a matter of changing window styles.

I suggest that this conversation be adjourned until and unless someone contributes a patch.

Here is an explanation of how it works right now for anyone that wants to explore. Please excuse my handwriting.

clientedge.pdf 38.8 KB   Download

An example program is not a patch.

Until then, please stop.  Every time you comment, 45 people who starred the issue have to clean their inboxes.

Snark about drunken teenagers with Parkinson's disease (comment 12) and armchair engineering are not helpful.

To prevent further vaginal irritation, someone from Google should restrict comments to this issue.

Well I for one am all for Alex working on this issue. Stop whinging about cleaning your inbox - if this issue can be fixed, no one will care. Alex clearly feels the same way I do about this, and if the rest of you don't like it, go away.

@Alex: The example you provided clearly shows that this is both possible, and hardly a major drama to implement. Admittedly I've never done GUI stuff without a library in native C, which is why I haven't taken the time to fix this myself.
That said, Alex, if you could fix this issue, it would mean you're improving the interface as a whole (not just moving caption buttons). I think many (especially myself) would be supremely grateful if you could patch this. :)

Ok, so after working with Chromium in a debugger for the better part of today stepping through code and changing drawing coordinates, I'm starting to think it may well actually be impossible to correctly position the caption buttons, as well as have metric-correct borders, with your current interface code. I could well be wrong, but I can't be sure unless one of the team can explain to me exactly how the main-window is being painted.
The first WM_PAINT message I hit for the main window gives me a white window with the left, bottom and right borders drawn. It is possible to see the right-most line of pixels of the close button in the right border at this point. The rest of the window gets painted in one massive chunk upon the return from the WM_PAINT wrapper function, but I don't really know what's going on there because of that god forsaken define-freaking-mess-aka-class that wraps window messages.

Sometime over the next couple of days I will attempt to convert the main window into a client-only window, and see how I go without annoying borders to contend with. At this point however, unless I'm misunderstanding what's going on in terms of painting, I'm thinking this will just result in the same problem, just without borders?

An important thing to note should this actually be unable to be fixed - there are two options which can be explored:
-1. Rewrite the interface code, and design it to more correctly work with DWM's annoyances. Or...
-2. Let the borders be metric-incorrect.
Lets face it, sure the incorrect positioning of the caption buttons is barely noticeable, but of all the metric-defying applications I've seen, I've not once seen an application incorrectly position the caption buttons until Chromium. Metrics are there for customizability, the caption buttons for functionality. Would it not be better to have a UI problem in the realm of customizability, rather than functionality? I don't know about everyone else, but I find 3px-too-thick borders to be infinitely better looking than 3px-too-far-to-the-right caption buttons - I'd even go as far as to say the metric-incorrect borders remain looking natural.

Anyway, would it be at all possible for a Chromium team member to follow up on this post please? I'd like to hear your thoughts on the possibility of having metric-incorrect borders, and also I'd like some info on the paint-process if possible.
Thanks.

I think it's interesting to see that f.e. Office can handle it, being completely ownerdrawn, too. And office draws up to the top of the window (f.e. if you add an image, you get that pink extra-tab that goes up to the top. the window title is own-drawn, too).

at the same time, chromium, for some reason, does NOT draw the tabs up to the top, except when maximized. so it could a) draw them a little bit lower, and not having any need to have an ownerdrawn window at all, or move them up to the top to save some space in height.

and yes, it looks like there's a need for a full rewrite if that problem isn't fixable with the current code. If i had the time..

so in short, 3 things:
1) others can do it
2) can you save more vertical space, too, at the same time?
3) or lower the tabs a bit to remove the ownerdrawn need.

@daveper...@gmail.com:
The reason Office can do what it does is because technically it doesn't have a window border (non-client area) at all - its being removed, and a new one is being drawn in the client area thus giving the appearance of proper window borders.
This is what I'll be attempting to implement in Chromium over the next couple of days, time allowing. It allows for much more flexibility when drawing the UI.

Just to note, regarding the last few comments about fixing this via making the whole window client area, like Office does: the whole reason we filed this bug was to suggest that very approach (see comment 0 or the title), which is the only way we think this will be fixable given our other constraints.  (Having wrong-sized borders on the side, for example, is in our opinion worse than mispositioning the caption buttons.)

So, before too many people think we're idiots because "other apps can do this", consider that we at least reasoned our way that far -- and in fact implemented a prototype, which didn't work (see comment 2) -- before filing this bug in the first place.

Actually Alex, Firefox's borders are larger than standard windows metrics by 2px.
I have attached four images. The first is a comparison of Firefox's border with the metric-compliant border of Notepad. A red line clearly shows the 2px difference with Firefox. The second and third are screenshots of Firefox 4 and Chromium respectively, with Chromium having its 3px too-wide borders (I've included both, as my system metrics are set to the default, whereas Alex's aren't). The fourth is a mockup of Chromium with border widths that are just 2px too wide (read on for explanation).

The important thing to note here is that the difference between Firefox's and Chromium's borders is only 1px.

pkasting, I propose a compromise: What say we alter Chromium's visual style ever so slightly and reduce the outset-shadow on the edge of the client area by one pixel, which will mean conforming to Firefox's border widths, and leave it at that? That would mean only a 2px discrepancy between the metric, and the border itself.

I have to say I agree with Alex - I don't think that there should be a bug with the caption buttons (which are functionality), instead of a bug with metrics (which are customizability), when you are given the choice between the two as a result of implementing a non-standard visual-style. Please understand - I am not calling you incompetent, or stupid, or idiots, or anything like that. Windows caption-buttons are positioned by the DWM relative to the right-side of the client-area RECT. The fact that you are changing this, means you're breaking the standard anyway (yes, you're given the functionality, but that doesn't mean use it. I mean hell, we can do void main() {...} in C++, but we sure as hell shouldn't). My point is, you break the standard implementation of your GUI form, yet expect to be able to then conform to the standard of system metrics. This doesn't make sense from a logical standpoint. I believe, as Alex does, that this should be put to vote with the options being:
1) Leave as is until someone can implement a client-only form.
2) Expand the border to make it 3px wider than the system-metric.
3) Compromise, and reduce the outset-shadow by 1px and don't expand the client area at all, which will create borders whose width match Firefox's borders.

As I said, I will try to convert the form into a client-only form, however as I previously said I'm not very well versed in native GUI code and am still having some issues following the flow of Chromium's code itself.

	Firefox_Notepad.png 4.1 KB   View   Download

	Firefox.png 170 KB   View   Download

	Chromium.png 102 KB   View   Download

	Chromium_2px.png 99 KB   View   Download

but I noticed this user comment in MSDN:

"Be sure to add WS_THICKFRAME to your window style, or the caption buttons will appear shifted several pixels to the right.  This can have much more noticeable effects if the display settings of the target computer use a DPI setting other than 96."

http://msdn.microsoft.com/en-us/library/bb688195%28VS.85%29.aspx#removing

Sorry if this is not useful -- I have no easy way to check and don't have Chrome installed to see if it already has the window style -- but I thought it might be an easy fix that had been overlooked until now.


Regarding Firefox 4 vs Chrome, while it doesn't change much it's worth keeping in mind that the Firefox 4 window frames are the standard size; they just *look* thicker because they don't have the usual 2 pixel black & white border drawn into them. (Instead, there's a 1 pixel black border drawn entirely in the client area.) I guess if you could draw into the non-client area you could paint the border in the standard place again.

I agree that Firefox 4's thicker-looking borders are preferable to Chrome's misplaced close buttons, FWIW. (Although, personally, I wish neither browser messed with the standard window borders, system menu or icon at all. :( At least as an option. I like those and use every one of those things the way they are.)

WS_THICKFRAME is already set. It'd be nice if it were that simple, but sadly its not.

As for Firefox's borders - does the image that I posted above not show that they are of non-standard width?

"WS_THICKFRAME is already set."

Ah well. :( Was a long shot!


"As for Firefox's borders - does the image that I posted above not show that they are of non-standard width?"


What I mean is, Firefox's window edges are the standard width, despite looking thicker. Its non-client border is the standard width and its client area starts at the standard place (ignoring the top of the window, of course).

The visual difference is because the usual inner non-client border is not drawn by DWM and instead there is a border drawn into the client area by Firefox.

In your screenshot, the red line is drawn 2 pixels inside of the non-client area, not at the edge of the non-client area. The non-client area includes that two pixel inner frame (which is blank glass in Firefox).

None of which really helps solve the problem (unless someone knows a way to draw into the non-client area to put the non-client frame back) but I figured the distinction may help understand what's happening.

I'm sure the distinction is old news to those who have been thinking about this issue for a long time, but it was something I hadn't realised until I looked at what the window was doing a bit more (and remembered having to draw the black & white lines myself in an app where I extended the glass frame slightly at the bottom).

BTW, one possibly very stupid question, but why do Firefox and Chrome both extend the left and right glass edges anyway? They only seem to need glass at the top, not at the sides? Are there worthwhile cases when the main web-page part of the window needs to have glass on it?

(In Firefox there is the Panorama/Tab-Groups feature, where the whole window is glass, but I imagine most people would rather the borders looked normal than have that feature at all. And, besides, you can always change the glass area on-the-fly.)

Actually I think you're right, Leo. My bad. Upon closer inspection things are exactly as you say they are: With the Firefox borders, it appears that they have opted to extend the frame into the client-area under the main content to remove the inset border (much like what Chromium does), and rendered their 'border' as the out-most pixel edge of the client-area. Technically speaking, their borders are perfect.

But this makes things much simpler! As my mockup shows, if we remove the outer 1px of outset-shadow from the client-area of Chromium, we can get the borders to match up with Firefox's appearance, and thus be metrically correct!
I'll see if I can't get a patch working for this - hopefully I'll be able to find where that outset-shadow is being drawn.

Firefox 4 is not "perfect"; its content begins 1 px too far to the right on my system compared with a Windows Explorer window.

The appearance of Chrome's borders today is pixel-accurate to what we want them to look like.

As I said before, we're happy to look at any patches to fix this bug.

Chrome UI is not designed by committee and is not subject to voting.  Final decisions are made by the UI leads acting as benevolent dictators.  I'm speaking here as a UI team member and author of much of Chrome's frame-drawing code.  The appearance of Chrome's frame edge is not subject to change on this bug.

Please do not waste any more of anyone's time by arguing about Firefox, what Chrome should look like, who has what authority, etc.  I don't want to lock this bug to non-committer comments, as it would inconvenience the folks who are trying to actually write patches.

pkasting, did you even read my most recent comment? Visibly, it looks as though Firefox has 1px too wide borders, but that is only because they draw their border *inside the client-area*.
I have attached an image to explain this. The red line shows where the non-client area of both Notepad, and Firefox ends, and the green line shows where the client-area beings. So as previously stated, Firefox's borders are technically fine, they just appear different because they aren't breaking the standard size for the client-area. They are instead opting to draw their border inside the client-area.

I have a question: If you have no authority to look into changing the visual-style in any way, can you please point me in the direction of a UI lead who does, or get them to post here? Obviously none of my explanations of how you're *already breaking the standard* in the UI aren't getting past you, so I would happily explain to a UI lead why what they signed off on is wrong, and why my compromise should be implemented AT LEAST until someone with more experience with native forms can make it client-only, should I fail. Or, if not that, at least take my suggestion to a higher-up yourself, instead of just blanket-banning any possible compromise.

	Firefox_Notepad_Correct.png 12.0 KB   View   Download

Why are you comparing Firefox with Notepad? Compare Chrome with Windows Explorer. They have the same Aero glass pixels but Chrome has a white border and Windows Explorer has a black border.

	Chrome_Windows_Explorer_Correct.png 3.9 KB   View   Download

Yes we know that. But this happens at the expense of the caption buttons at the top of Chrome's window being 3px too far right.

@53, We're talking past each other.  I'm not talking about whether Firefox' client or non-client areas are correct.  I'm talking about the horizontal offset from the edge of the window at which content begins, irrespective of what area is actually "client".

To put it in your terms, whether Firefox is "technically fine" is irrelevant, and whether it "appears different" is relevant.

I do have the authority to discuss visual style changes and I am telling you in that capacity that we are not changing the visual style.  It's not that you're talking to the wrong person, it's that we don't agree.  If we were interested in changing our visual style in order to fix the caption position we would have done it years ago.  See also comment 22.

Right, OK, thank you for clarifying that. At least now we're on the same page in that regard, however much I disagree.

I will continue to attempt to make the window client-only, but to be honest I don't know the code as well as you do so I don't know how far I'll get.

Progress report (for those who may be interested):
I have successfully converted the main Chrome form into a client-only window, and aligned the content and caption buttons metrically perfect. Its a shame I didn't know where to look, otherwise I would have saved myself hours of stepping through the code to look for one variable. No matter.
I am observing pkasting's black-flashing bug, and I believe I have an idea of what could be causing it. I will attempt to fix it when I wake up tomorrow, as its 1am right now and I'm tired. If all goes well, I should be able to submit a patch tomorrow (today? :P).

Awesome.  If you can fix the black flashing, I'm very interested.  Heck, even just understanding it would be great.

Make sure you test that the rest of the frame/content/etc. is aligned correctly in all combinations of the following cases:
* Aero (the "glass frame") versus Classic/Luna (the "opaque frame")
* LTR versus RTL (run with "--lang=he" to temporarily run Chrome in RTL)
* Top tabs versus side tabs (use about:flags to enable "Side tabs", and then use the tabstrip context menu to toggle)
* Unthemed versus with https://tools.google.com/chrome/intl/en/themes/theme_dots.html installed
* Normal windows and popup windows (use http://popuptest.com/ to get popups)

That's 2^5 = 32 total combinations, but hopefully if things are working well it should be very fast to test most of these (and you can skip a few if it's clear they'll obviously work).

Well, after a few unexpected bugs and a whole lot of testing, here is my completed patch for this issue. I hope its ok to post it here like this, but if not please forgive me - this is the first time I've submitted any code to an open-source project.

The patch is for r78688 of the source - I was unable to sync with the latest source revision since I'm currently having problems getting SVN to work on any of my systems. The patch has been thoroughly tested by myself under all the conditions you mentioned, pkasting. There are no bugs that I can find.

Oh, you wished to know what was causing the black flashing. In short, it was a double-buffering issue. Naturally, making a window client-only comes with the side effect that windows renders it differently to a standard window, which causes the black flashing because the screen refreshes faster than windows can render the DWM frame. The fix was simple - one simply has to apply WS_EX_COMPOSITED to the affected window, which enabled double-buffering.

pkasting, I feel I owe you an apology, for insinuating before that your code was somehow sub-par. The code is actually quite well written, if I do say so myself. One just needs to wrap their head around it. :)

So, what happens now?

clientonlywindows.patch 8.6 KB   View   Download

Nicely done! There are no performance regressions using WS_EX_COMPOSITED right?

http://www.kevs3d.co.uk/dev/asteroidsbench/

There are some instructions for getting a patch up for review at http://dev.chromium.org/developers/contributing-code .  If you can create a changelist on the code review site, set ben@chromium.org and pkasting@chromium.org as reviewers and use "Publish + Mail comments" to ping us to go look.

I glanced very quickly at your patch.  Make sure you use spaces everywhere and no tabs (indenting of one line looked off); use this_style_of_naming for local variables; and I'm not sure about setting WS_EX_COMPOSITED where you've done it (seems like maybe it should be added to the place where we set the other extended styles?).

I'm trying to read up on WS_EX_COMPOSITED; there's little documentation I've found so far.  It sounds like it can prevent the caption buttons from highlighting when you roll over them; can you test that?  It also sounds like it might cause problems for layered windows... is that why you had the "app window" check?

I know it shouldn't, I'm just citing things I've encountered other people running into as I've tried to look up more about this flag.

@Alex: No regressions that I am aware of.

@pkasting: I'm unable to create a change list, as the gcl command makes use of SVN to determine the changed files. For some reason SVN, on both of my machines, does nothing when run (doesn't work, no errors, no output at all), which was part of the reason I uploaded a diff patch here (another was that I find that page quite difficult to understand in some parts).
I have made the corrections you specified to the patch (sorry about that), and reuploaded it. Unless you can solve my SVN problem when my Google research itself cannot, the only way I can see this working is if either you or someone else downloads my patch, applies it, and generates their own change list.

Also, yes, WS_EX_COMPOSITED has little documentation, but as I said, I have tested this thoroughly. There are no issues with caption buttons that I have found. As to where I'm setting it - I read a comment in the code, just before all the styles are initialized to 0 that said "We initialize the styles to 0 here so other classes can override the default behavior before calling init.". Since I couldn't find another place where styles were being set for the app window, I set them there because I thought it was correct. And the reason I had the IsAppWindow() check is because the style only needs to be on app windows...?

clientonlywindows.patch 8.6 KB   View   Download

Are you using cygwin?  If not, you might want to try that to fix your problems.  See http://dev.chromium.org/developers/how-tos/build-instructions-windows where it says "install cygwin".

Already tried that, to no avail.

Still researching what's going on here.

AFAICT, the DWM normally double-buffers all windows, but for some reason, making our window all-client turns this off; then we get black because something that was supposed to have been painted isn't.  WS_EX_OVERLAPPED hacks around this by re-double-buffering us (albeit via a different mathod than the DWM uses).

This doesn't totally make sense to me: what, precisely, is not painting and when?  Why is it managing to paint once we double-buffer?  Why do other apps with all-client-area windows not see this problem?

Is the black all in the glass area?  If so, maybe the problem is that something isn't getting passed through to DwmDefWindowProc() that should be (and instead is either getting handled directly or sent to DefWindowProc()), since the DWM draws the glass rather than us.

In the examples of client-only windows I've seen, and one that I myself have written, if DWM is enabled, DwmDefWindowProc gets called no matter what window messages hit the window.
From what I understand of Chromium's message-handling, only specific messages are hitting DwmDefWindowProc... Perhaps this is the reason? I thought about doing this, but I didn't feel comfortable making a change that significant to the Chromium code (unless its a simple change and I missed it).
In answer to your question, yes, only the glass is what flashes black.

If that's the problem, I will try and fix it, but again I have no access to SVN, so short of submitting diff patches I can't do much. There's no point in me doing anything if my patches aren't going to get accepted. Yes, I realize I'm not submitting things in the correct way, but this is the best I can do given the circumstances. Are my diff patches likely to be picked up by someone and implemented? If so, I will continue working on this.

Yes, I will personally get your patches up for review as needed.  Have no fear :)

I think looking for a message (or more than one) that should hit DwmDefWindowProc() but doesn't is a very promising angle.  It would make sense as the cause of the black flashes, and it would be a fix with fewer side effects.  If it's not this, then there must be _something_ else we're doing wrong, or all apps would see these sorts of flashes.

Excellent, thank you. :)
I'm sorry to inconvenience you, but everyone I've talked to has no idea whats wrong with SVN for me.

I'm currently at college, but when I get home I'll delve back into the code and see if I can't work out what's going on here. Hopefully I'll find out what it is, as you're right - other client-only windows don't need this style set to work, so Chrome shouldn't either.

Update: I'm pretty much at wit's end in terms of a solution to this problem other than WS_EX_COMPOSITED. I restructured the message-handling in Chromium to match the code-flow/process of one of my client-only example programs, passing everything by DwmDefWindowProc, and nothing. No improvement whatsoever.
The *only* thing I can think of at this stage that could be causing it is the fact that Chromium's interface is rendered with Direct2D, instead of GDI+. I can't be certain, but at this point I can see nothing else that would be causing this kind of issue. As I understand it, Office '07's interface is rendered with GDI+ (although I'm not 100% sure on this), so that would explain at least why it doesn't require WS_EX_COMPOSITED.

I found an interesting article while researching WS_EX_COMPOSITED: http://www.codeproject.com/KB/directx/umvistad3d.aspx
This particular project is using Direct3D rather than Direct2D, so whether it applies or not I don't know, but the author puts emphasis on the fact that without WS_EX_COMPOSITED, what he is creating would be unbearably laggy. He goes on to speculate why, although it is only that - speculation.
Information on this style is somewhat fragmented, and the only real consensus is that it enables double-buffering (which we know).

My time is likely to be constrained over the next few days, but given the opportunity I will continue to research this problem. If it turns out that it is because we're using Direct2D, then we will have no choice but to employ the use of WS_EX_COMPOSITED (which isn't actually that bad, as testing shows there are no adverse side-effects). In the event of this scenario, I have found a much cleaner place in the code to assign the style to the windows, and have added a TODO note should anyone care to research an alternative in the future. The updated patch is attached (again, for r78688 of the code). Whether you want to submit this patch as is pkasting, or wait for any additional word from me/anyone else is up to you, but aside from Direct2D I honestly can't think of a cause for this. Since Direct2D is out of my skillset, this patch may well be the best I can do.

ClientOnlyWindows.patch 9.1 KB   View   Download

We're using Direct2D?  That surprises me; we at least used to use GDI, and the only Direct2D work I'm aware of is speculative, future-focused research.

No, it seems not. My bad. I saw two includes: one for CanvasDirect2D, and one for CanvasSkia, and assumed Skia was something Mac/Linux specific and not used for Windows. That was a silly assumption to make. Sorry for the confusion.

As it stands, I'm still yet to come up with another solution for this. The closest I've gotten is if you remove the WS_CLIPCHILDREN style from Chromium's main window, it prevents the black-flickering on the glass borders, however then the window contents don't get drawn properly. Might this be an avenue I should investigate further? Would it be better than setting WS_EX_COMPOSITED in your opinion?

Wow, that's an interesting finding.  I have no idea what to make of that.

Well upon research of that style, I have a theory as to why it fixes the glass - removing it makes the window paint faster. The following is only speculation mind you, but at this point its the only explanation I can come up with...
The WS_CLIPCHILDREN style, as I'm sure you know, tells windows to repaint the entire window EXCEPT the regions occupied by child controls. Its possible that the performance hit caused by the exclusion of these regions is causing the glass to be rendered a few frames too slow, thus the black flashing. Again, this is only speculation however.

 Issue 9184  has been merged into this issue.

 Issue 13061  has been merged into this issue.

(No comment was entered for this change.)

Here was a suggestion from a helpful Microsoft employee:

"It's likely your background erase stomping the alpha channel. You can verify this in a sample app by changing your class background brush to GetStockObject(NULL_BRUSH) when registering the toplevel window class. NULL_BRUSH as opposed to NULL is useful because that's what USER will fill new areas of your redirection bitmap with before you even know they're invalid."

I'm not sure whether that's relevant to us (as I thought we no-oped WM_ERASEBKGND; but maybe that's not what this is talking about), but if it helps anyone have an insight...

Yeah I'm pretty sure you did no-op it, but I'm not 100% sure as I don't have the source in front of me (I'm away, and will be for the next 10 days at least)...
I can make a sample app as described here I guess, though...

Well if a WNDCLASS.hbrBackground == (HBRUSH)GetStockObject(NULL), then there is occasional flickering across the window during resizing. USER_NULL, or even WHITE_BRUSH fixes this issue... Might be worth taking a look at the source and seeing what's happening during the initial class creation for the window.

Wait... I meant NULL_BRUSH, not USER_NULL. My bad.

 Issue 85040  has been merged into this issue.

 Issue 88060  has been merged into this issue.

 Issue 93364  has been merged into this issue.

 Issue 107298  has been merged into this issue.

Hi again, guys. It seems my patch was never put through after all. No matter. I've grabbed a recent revision of the source and have decided to take another look at this issue.

I've taken the newer code (which is much easier to work with, btw), and have built a version of the browser that uses a client-only main window that shows the black flickering upon resize. Now as per above comments, I've been debugging for the past hour or so and have isolated the routine that creates the initial window class for the main browser window, and have modded it to set the hbrBackground property as shown above with no improvement at all.

Does anyone have any other ideas? I mean we know WS_EX_COMPOSITED works, but as you say, there must be a better method.

I should ask though: If we can't fix the issue by other means, would it not be better to implement a solution with WS_EX_COMPOSITED until an alternative can be devised? Surely a weird fix is better than no fix at all? :P

Maybe.  This is fully paged out of my head at this point.

It's worth noting that in the long term, Windows is going to move to using Aura at its core.  We haven't really started that yet so there's nowhere to go look into how windows are drawn in that case, but eventually that's where things are going.

Yes I figured that. I guess I left it too long to take another crack at it. :S

But I think this makes things a whole lot clearer. There is no point making significant code changes to the Window drawing in order to fix this black flashing when you're going to transition into a new drawing system. I know I've personally done test-case after test-case to try to work out why this black flashing is occurring, and come up with nothing. I can't even replicate the issue on my test client-only app anymore, so who knows what happened there (probably a win update or something, I guess :S).
Given this impending transition, I think it's fair to say that the simplest solution would be the best solution. We know WS_EX_COMPOSITED works, so why not put it in for now with a note, and if the problem still exists after the transition to Aura, drop me a line and I'll begin looking into it again. :)

I'll do some testing to make sure my build doesn't have any side-effects, and if you're willing, I'll (try to, assuming SVN doesn't break again) generate a change list and you can look over it.

That said, don't assume I don't feel as you do - I know this solution isn't the best (and would much rather fix the issue in a better way), but until we get someone who knows what is causing this, we should put this in temporarily at the very least to stop people posting duplicate bug reports. Rest assured that once we actually find out what's causing the problem, I'll be back in to fix the code properly.

Hmmm. An issue has arisen with the use of WS_EX_COMPOSITED that wasn't present in the last revision of the source I worked with (no idea why it's doing it now). Apparently when DWM/Aero is disabled and an attempt is made to run Chrome with WS_EX_COMPOSITED, CPU usage jumps to max and stays there. The window updating thus becomes extremely laggy. Removing the style fixes the issue.
Naturally the fix is easy - handle the WM_DWMCOMPOSITIONCHANGED message and set the style accordingly, however this is very untidy in terms of a solution. I'm reluctant to implement this as a way of fixing the black flashing, so as much as I hate to say it, I guess there's currently nothing that can be done about the caption button issue. I'll prod around in the code over the next few days and try a few things, but we're pretty much back to square one I'm afraid. :(

Right! I believe I've made some headway in determining the cause of the black flickering issue.
I started with a breakpoint on NativeWidgetWin::OnPaint (the WM_PAINT wrapper) and after an hour of stepping through code and endless restarts, I've ended up in BitmapPlatformDevice::Create. Something is getting done wrong in this function, however I've no idea what nor how to fix it. Basically, the first WM_PAINT message the main window receives results in most of the interface being painted, however all the Aero glass is painted over in black. The second and subsequent WM_PAINT message(s) sort out the issue and return the glass to normal.
Now (and I speculate here, since I haven't tested this specifically) I suspect this is what's happening when the window get's resized - 2 WM_PAINT messages with the first stomping the glass, and the second restoring it, thus, flickering black.

I should be studying for an exam, so I'll have to leave it here for tonight. Any insight anyone can provide me here would be greatly appreciated, because as I said, I don't know what's actually going wrong. :S

Apparently I was wrong - a second WM_PAINT message doesn't fix the glass - something else does.
I'm pretty much at wits end here. I have no idea why when the window has a non-client area, any bitblitting doesn't seem to touch the glass frame that is extended into the client area, yet take the non-client area away and suddenly bitblitting destroys the glass frame by painting over it in black. What really confuses me here is that black pixels where the glass border is are supposed to be replaced by the glass frame itself (this is why extending the frame on windows requires a black background), yet for whatever reason that simply isn't happening here. :S

I think I might try working backwards on this one. I'm getting nowhere with Chrome's code at this point. Unless someone can either give me some insight I don't have (even a small amount!) I think my best bet might be to try and replicate this issue on a reduced test-case and go from there.
That said, this issue is trying my patience, haha. I daresay if I can't find a fix soon, I'll have to leave it in someone else's hands.

Just wrote a multi-paragraph post to have it erased when I tried to submit. FFS. :/

Anyways, yeah, I can't be certain but I strongly believe at this point that it's GDI that's breaking things. You're painting to an offscreen bitmap then bitblitting in the result - as soon as that bitblt hits the window, glass is destroyed. I don't know much about SkiaBitmaps to know whether it's not setting the alpha values properly, or whether GDI is ignoring those alpha values (more likely the latter), but yeah that's why things are flickering black. I suspect WS_EX_COMPOSITED fixes the issue by taking what is about to be drawn, checking for black pixels within the bounds defined for the DWM frame, and replacing them with glass. If it is GDI causing the issue however, either WS_EX_COMPOSITED would be required, or drawing would need to be shifted to GDI+ or Direct2D, and I'm not sure I have the skill to do that.

On reading through the code, I've found numerous references to flickering issues that may or may not be the same issue as we're experiencing now (but for a window *with* a non-client area) with little hack fixes that are likely the reason everything looks fine on a standard window. This tells me that the issue with Chrome's visual style arose later in the UI code development rather than sooner, meaning that the architecture was in place for a window with a non-client area by nature. Yes, it's trivial to go into WM_NCCALCSIZE and make the window client-only, but the rest of the design expects there to be a separate non-client area and has drawing fixes in place to make everything look smooth. Take the simplest example I can think of - the non_client_view_ field - should this be present on a client-only window? Probably not, but the current design requires it for some specific functionality. Assuming I understand the code correctly, that field should really, logically speaking, be set to null when dealing with a client only window. It's things like that that make it impossible to simply change some variables to make a client-only window without going over the design as a whole.

I believe that if this issue is ever truely going to be fixed, someone needs to rewrite the windows UI code from the ground up, making the idea of a client-only window a primary focus. One can't design for a specific situation, change the expected result, then expect the rest of the design to work automatically. As was said above, making a client-only window as opposed to a standard window will "probably simplify all the aero glass nonclient code" - this is very true, but making a change then going over the rest of the code to this end is not a good path to take. The design needs to be rethought with the idea of a client-only window from the start.

Perhaps when transitioning to Aura, this could be a primary design concern (depending on how things are drawn there). But as it stands, I don't feel I have to skill required to sit down and reimplement the window's UI code myself, and since there is no one else so much as posting here anymore...
I tried, but I don't think I can do anymore. Sorry guys.

The shift to Aura may do precisely what you suggest.

I just don't think there's a choice, really. As I said even fixing the issue directly would leave a lot of redundant code around, so a ground up approach is, I believe, what is required.

 Issue 181378  has been merged into this issue.

(No comment was entered for this change.)

It's 2014. Aura's been implemented. This still happens.

We still use the glass frame when there's no Chrome theme, so there's no change related to Aura for this bug.