Note that we are switching to native notifications fairly soon (enable chrome://flags#enable-native-notifications so not sure how worth is fixing this in the old system.

Hmm, OK. I'm excited about that — I knew it was in progress but not how close. I think I have a fix (and it's fairly tiny) for the current system, so I want to land it in case anything delays the flip, if that sounds reasonable to you.

Ah yes, I just saw it in the other bug. Let's land the simple fix for now. It might even make M55 branch point..

MCPopupWindow used to be a NSPanel subclass but was changed to a NSWindow with this CL: https://chromium.googlesource.com/chromium/src/+/ba96ee71b35d61b5dfcecc01a5c5f1568ed001c8

Urf, I'm not sure if you saw the bug or the CL, but that was going to be my fix:
https://codereview.chromium.org/2393323005/

Thanks, will check out that bug.

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

commit 629a5d065848adbac50931ae305a3d8597578e4d
Author: sdy <sdy@chromium.org>
Date: Tue Oct 11 19:10:32 2016

[Mac] Use a nonactivating panel for notifications so that mouse down doesn't activate Chrome.

Currently, pressing the mouse button over a notification brings Chrome
to the front, even though the tab which sent the notification won't be
shown unless it calls `window.focus()` from its onclick listener.

This CL switches notifications to use NSPanel, which can receive mouse
events without activating the application.

Notifications were previously switched away from NSPanel to work around
 crbug.com/459306 . I tried fairly hard to repro that issue with this CL,
and couldn't. If it comes back, I feel okay about reverting this change
or taking another crack at its root cause.

BUG= 653868 

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

[modify] https://crrev.com/629a5d065848adbac50931ae305a3d8597578e4d/ui/message_center/cocoa/popup_controller.mm

Please make sure this doesn't regress issue 470830 (using the steps to reproduce from the original report). That issue was a problem for us in Jun 2015, but by Oct 2015 it had started working as expected without explanation. In hindsight, it seems likely that https://codereview.chromium.org/1275363004 is the reason it started working, and hence https://codereview.chromium.org/2393323005 seems likely to regress it.

If this patch does turn out to regress issue 470830, then https://codereview.chromium.org/1411243012 (which I had abandoned because it was no longer necessary) might fix the regression.

johnme@: Thanks for catching this, you're totally right. I just submitted a modified version of your CL, since things moved around: crrev.com/2420733002.

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

commit 6759df3b42a5d4dcd95dbefb72e2c0ce2e220730
Author: sdy <sdy@chromium.org>
Date: Sat Oct 15 22:08:40 2016

Bring Chrome to the front when opening a URL from a notification

Based on crrev.com/1411243012; see  crbug.com/653868#c8 .

BUG= 653868 ,470830

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

[modify] https://crrev.com/6759df3b42a5d4dcd95dbefb72e2c0ce2e220730/content/browser/service_worker/service_worker_client_utils.cc
[modify] https://crrev.com/6759df3b42a5d4dcd95dbefb72e2c0ce2e220730/third_party/WebKit/LayoutTests/http/tests/serviceworker/chromium/clients-openwindow.html

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

commit 6759df3b42a5d4dcd95dbefb72e2c0ce2e220730
Author: sdy <sdy@chromium.org>
Date: Sat Oct 15 22:08:40 2016

Bring Chrome to the front when opening a URL from a notification

Based on crrev.com/1411243012; see  crbug.com/653868#c8 .

BUG= 653868 ,470830

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

[modify] https://crrev.com/6759df3b42a5d4dcd95dbefb72e2c0ce2e220730/content/browser/service_worker/service_worker_client_utils.cc
[modify] https://crrev.com/6759df3b42a5d4dcd95dbefb72e2c0ce2e220730/third_party/WebKit/LayoutTests/http/tests/serviceworker/chromium/clients-openwindow.html

+dimu@, do you have any idea why it applied "merge-merged-2892" label at #12?

Likely because someone tried to recreate the branch by hand - +mmoss@ / dimu@ should be able to comment on that, likely related to branch.py failures over the weekend.

That's been the cause in the past, though I'm not aware of any attempt to recreate those failed branches, and this is exactly why I wanted to just bump to 2893, rather than trying to fix 2892. Maybe some random person was trying to be "helpful".

Migrating to more generic platform label, so that it can be applied to other platforms (i.e. I love the idea).