able to reproduce the issue on Blaze using chrome version 53.0.2768.0/8459.0.0

kavvaru@ can you confirm you can see it in the latest M53 Beta build?

abodenha@ can you please suggest an owner for this issue?

With response to comment#2: Checked on latest beta 53.0.2785.55/8530.47.o beta channel daisy and on latest dev c 54.0.2822.0/8687.0.0 dev-channel daisy. Issue is still reproducible. i.e Default focus is not seen on those Close/Minimize/Maximize buttons.

still able to reproduce the issue on peppy using latest chrome version 53.0.2785.55/8530.48.0

 Issue 629064  has been merged into this issue.

rkc@ are you investigating this issue? It is currently a stable blocker and has been open since June 16th.

I really don't have the cycles to look at this right now. Albert, anyone else that can pick this up?

jennyz@ any chance you can take a look?

jennyz@ will you be looking at fixing this one?

Took a quick look. It looks like the Close/Minimize/Maximize button state is not right all of the apps. For example, if you launch calculator, the buttons shows as highlighted initially, but if you switch the focus to chrome or another app, the buttons on calculator does not dim. Vice versa, if the buttons on calculator is not highlighted, it stays the same way you switch the focus to it. 

For hangout, it is is just that the initial state got wrong, and stays wrong. 

Does anyone in QA team knows from which version the regression starts to happen?

kavvaru@/pucchakayala@ can you please comment on #11?

Tried R54-8717.0.0 build. This issue is fixed. It looks like the regression has been fixed in main branch. We need to find out the fixing cl and merge back to R53.

perfect. thanks for the update JennyZ@. Let me know when you need approval to merge.

On Tot(R54), it looks like the following revision fixed the issue:
https://crrev.com/6cc4373556f64bec8cbe8d3e2ec98c50675459d3

More specifically, the change in custom_rame_view_ash.cc for rescheduling paint for the frame header for ActivationChanged event is the fix.
https://codereview.chromium.org/2227643003/diff/60001/ash/common/frame/custom_frame_view_ash.cc

But we can't just bring this one over to R53 to fix the issue since it is part of another refactoring in R54.
https://codereview.chromium.org/2222653002

I need to take some further look to see what is the best way to fix it in R53. 

sky@, you are the owner of both cls. Do you think we should merge the change from R54 to R53, or fix it differently in R53?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/649bbf1072becc8a48eb21b9afd3a3facf6e9ef2

commit 649bbf1072becc8a48eb21b9afd3a3facf6e9ef2
Author: Jenny Zhang <jennyz@chromium.org>
Date: Tue Aug 23 19:28:39 2016

Fix the issue of app window frame header buttons not being repainted when its activation state changes.

BUG= 620628 
TBR=sky

Review URL: https://codereview.chromium.org/2268863006 .

Cr-Commit-Position: refs/branch-heads/2785@{#731}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/649bbf1072becc8a48eb21b9afd3a3facf6e9ef2/ash/frame/custom_frame_view_ash.cc
[modify] https://crrev.com/649bbf1072becc8a48eb21b9afd3a3facf6e9ef2/ash/frame/custom_frame_view_ash.h

I picked the change in custom_frame_view_ash.h/cc and manually changed them in R53 files, since they were moved to a different directory in R54. 

Please verify the fix once it is available in canary for testing.

The cl of #16 is in R53-8530.68.0 with chrome 53.0.2785.80. Please verify.

verified on 53.0.2785.144