Narrow Bisect : 
https://chromium.googlesource.com/chromium/src/+log/bbea865be4f600c35292aff11dc6e6f34232578e..b255e7d02cb6f7d6cdd9308a97c796323396cc06?pretty=fuller&n=10000

Suspecting: r422973 or 422989 ? from Narrow Bisect

@rsesek : Please help to re-assign if your change is not the cause for this issue.

well it can't be 422989 because that only affects chromeos and this is a mac bug. rsesek's change does look more likely.

If r422973 is the problem maybe we can just revert it for now and reland after branch point?

 Issue 653474  has been merged into this issue.

I have a fix.

https://codereview.chromium.org/2395083003/

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

commit 6d3dbe8eb6ff81ed2c9e89df2e13d1764056e9d7
Author: rsesek <rsesek@chromium.org>
Date: Thu Oct 06 18:14:41 2016

Use -[NSApp activateIgnoringOtherApps:NO] instead of -[NSRunningApplication activateWithOptions:].

In c57771b074f8, +[BrowserWindowUtils activateWindowController:] was changed
from using Carbon's SetFrontProcessWithOptions(). This caused an activation bug,
 https://crbug.com/653483 , to occur. The difference in behavior is because the
NSApplication method internally calls _NXActivateSelf(), which uses
SetFrontProcessWithOptions(). The NSRunningApplication method instead messages
LaunchServices to set the front process.

The NSRunningApplication method appers to deactivate the app if it is currently
active, which caused the bug. Switching to the NSApplication method resolves
the issue and restores the old behavior. An alternatieve to using the
NSApplication method would be to make calling the NSRunningApplication method
conditional on -[NSApp isActive].

BUG= 653483 , 650845 
R=avi@chromium.org

Review-Url: https://codereview.chromium.org/2395083003
Cr-Commit-Position: refs/heads/master@{#423590}

[modify] https://crrev.com/6d3dbe8eb6ff81ed2c9e89df2e13d1764056e9d7/chrome/browser/ui/cocoa/browser_window_utils.mm

Verified the fix on the latest M-55(55.0.2883.6) on Mac OS 10.11.6. This is working as intended hence adding the verified label. Attached is the screen-cast of the intended fix. 

Deleted: 653483.mp4 312 KB

	653483.mp4 312 KB View Download

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

commit d694190ff0e1e1d594ccd644f807a1309ee61d5e
Author: sdy <sdy@chromium.org>
Date: Mon Oct 10 18:02:34 2016

[Mac] Pass YES to activateIgnoringOtherApps: to actually activate Chrome.

Passing NO doesn't activate our app in most cases; it seems to be mainly
useful when an app is launched (so there may be a long delay before it's
ready to become active) but the user might have switched to another app
in the mean time. In that case, the activation isn't the immediate
result of a user gesture, so it shouldn't steal focus.

This is a recent regression from crrev.com/2386343004.

BUG= 654441 , 653483 , 650845 

Review-Url: https://codereview.chromium.org/2409623002
Cr-Commit-Position: refs/heads/master@{#424182}

[modify] https://crrev.com/d694190ff0e1e1d594ccd644f807a1309ee61d5e/chrome/browser/ui/cocoa/browser_window_utils.mm

Verified the fix on MAC 10.11.16 using chrome dev version #55.0.2883.11 as per the steps mentioned in the comment #0.

The steps followed to reproduce the issue are as follows:
-----------
1. Launched chrome and opened a new tab page.
2. Pressed ‘Cmd + <‘ to open settings page.
3. Observed that the browser tab-strip appeared grey and looked active as expected.

Hence, the fix is working as expected.

Attaching screencast for reference

Adding the verified labels.

Deleted: 653483.mp4 456 KB

	653483.mp4 456 KB View Download

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

commit 6d3dbe8eb6ff81ed2c9e89df2e13d1764056e9d7
Author: rsesek <rsesek@chromium.org>
Date: Thu Oct 06 18:14:41 2016

Use -[NSApp activateIgnoringOtherApps:NO] instead of -[NSRunningApplication activateWithOptions:].

In c57771b074f8, +[BrowserWindowUtils activateWindowController:] was changed
from using Carbon's SetFrontProcessWithOptions(). This caused an activation bug,
 https://crbug.com/653483 , to occur. The difference in behavior is because the
NSApplication method internally calls _NXActivateSelf(), which uses
SetFrontProcessWithOptions(). The NSRunningApplication method instead messages
LaunchServices to set the front process.

The NSRunningApplication method appers to deactivate the app if it is currently
active, which caused the bug. Switching to the NSApplication method resolves
the issue and restores the old behavior. An alternatieve to using the
NSApplication method would be to make calling the NSRunningApplication method
conditional on -[NSApp isActive].

BUG= 653483 , 650845 
R=avi@chromium.org

Review-Url: https://codereview.chromium.org/2395083003
Cr-Commit-Position: refs/heads/master@{#423590}

[modify] https://crrev.com/6d3dbe8eb6ff81ed2c9e89df2e13d1764056e9d7/chrome/browser/ui/cocoa/browser_window_utils.mm

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

commit dcb9b2152f0875df5fa0352b92da1ee97e2bba89
Author: Robert Sesek <rsesek@chromium.org>
Date: Wed Oct 12 23:16:57 2016

[Mac] Pass YES to activateIgnoringOtherApps: to actually activate Chrome.

Passing NO doesn't activate our app in most cases; it seems to be mainly
useful when an app is launched (so there may be a long delay before it's
ready to become active) but the user might have switched to another app
in the mean time. In that case, the activation isn't the immediate
result of a user gesture, so it shouldn't steal focus.

This is a recent regression from crrev.com/2386343004.

BUG= 654441 , 653483 , 650845 

Review-Url: https://codereview.chromium.org/2409623002
Cr-Commit-Position: refs/heads/master@{#424182}
(cherry picked from commit d694190ff0e1e1d594ccd644f807a1309ee61d5e)

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

Cr-Commit-Position: refs/branch-heads/2883@{#77}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/dcb9b2152f0875df5fa0352b92da1ee97e2bba89/chrome/browser/ui/cocoa/browser_window_utils.mm

[Automated comment] removing mislabelled merge-merged-2840