Unable to reproduce the issue on Mac book pro retina 10.12.1. Could anyone from MTV team please look into this issue using Touchbar Mac version.

Hence, adding the TE-NeedsTriageFromMTV label.

Thanks..!!

mac triage: tagging Needs-TestConfirmation. Does anyone have a touchbar mac handy?

I have one, and i've confirmed it's definitely only an issue with touchbar mac's

z@: Can you please post the recent report id from chrome://crashes and/or the Apple crash log ?

Thanks in advance!

Hi, i'm not sure how to access Apple crash log but i don't see any reports on chrome://crashes. Perhaps because it never crashes? I just have to force quit the browser to quit

Okay, can you please analyze then the hanging process via the Activity.app and attach file here?

Thanks in advance.

after about 30 seconds of trying to quit, there's no chrome activity in Activity.app. Looks like this: https://dl.dropbox.com/u/891706/Swiftdrop/Screen%20Shot%202016-11-30%20at%2000.18.07.png .

But the app is still open according to the dock: https://dl.dropbox.com/u/891706/Swiftdrop/Screen%20Shot%202016-11-30%20at%2000.18.16.png

z@: You have a lot of processes. Have you filtered for "Chrome" ?

rsesek@: Do you know if this is a known issue with the new MacBooks?

Thanks.

found it - it's at 0.1 cpu.

Also, just to show you that others with the touchbar macbook pros are experiencing the same... I asked someone on twitter who has one to test: https://twitter.com/bryanrbeal/status/800697137650614272

I can reproduce this with the Touch Bar simulator.

This is really bad. Marking RBS for M55. We'll likely need to get this in a stable update. 

Given we're already rolling out M55stable, this shouldn't block the current rollout (since it's in m54 also), but this needs to go into a M55 stable refresh. It can not wait until M56 to get to stable. 

I misspoke. M55 isn't yet rolling out to stable, but regardless, this should not block promotion of the current candidate to stable. 

lgrey@ - just wondering what you have to get started on this. E.g. do you have a sample of the browser process? I'm assuming you don't have access to one of the new Touch Bar Macs?

It reproes in the simulator (at least via right-click on the Dock icon, I can't trigger it by tabbing back in and quitting via shortcut/menu item.)

So far, I've determined that the browser window controller never gets released in this case, which prevents the final shutdown from triggering. Currently trying to figure out why.

We have a semi-fix for this in that Chrome will quit, but only after it's foregrounded. According to rsesek@, getting the rest of the way will require going through the disassembly.

shrike@/pinkerton@: What's the timescale on pushing a stable refresh? Should I send what I have and follow up later, or wait until it works 100% as expected?

+govind for M55 release management. I think we should go ahead and land then merge the partial fix, it's way better than nothing.

Please request a merge of partial fix once change is baked/verified in Canary and safe to merge to M55 so we can pick it up for next week or later stable refresh release.

 Issue 668954  has been merged into this issue.

Fix in the CQ: https://codereview.chromium.org/2550463002

Filed rdar://29467717

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

commit 0098a25b70b91b23e87a4644e30722ba151e66e2
Author: lgrey <lgrey@chromium.org>
Date: Thu Dec 01 23:34:08 2016

[Mac] Opt browser window controller out of being a touch bar provider

Currently, on touch bar Macs, the system retains a reference to every
object it finds that conforms to the NSTouchBarProvider protocol, which
includes NSWindowController. If the user tries to quit Chrome when it
isn't foregrounded (for example, from the Dock icon context menu), these
references are never released, which means the browser window never
deallocs.

Since all browser windows being closed is a precondition of quitting,
Chrome never quits. There are a few private mechanisms to force the
touch bar to update its providers, but no matter what, the references
aren't released until Chrome is foregrounded.

This change effectively opts the window controller out of being a
touch bar provider which prevents it from being retained by the
touch bar mechanism in the first place.

BUG= 667274 

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

[modify] https://crrev.com/0098a25b70b91b23e87a4644e30722ba151e66e2/chrome/browser/ui/cocoa/browser_window_controller.mm

mark@ - given the explanation in c#27, what are the implications for Chrome updates? I.e. if the user chooses Chrome -> About Google Chrome, gets an update, and clicks the Relaunch button, it sounds like the browser will just hang? At that point the user's only recourse will be to force quit the app? Any other complications you can think of?

Based on what Leonard wrote in comment 27, the problem only occurs when Chrome quits while it’s not the foreground app. If you’re clicking the Relaunch button, Chrome’s the foreground app (there’s no “click-through” if it’s not foreground), so the bug shouldn’t bite.

Verified on a 15" Touch Bar MacBook Pro with canary 57.0.2939.0.

Tested the above fix on Latest Canary#57.0.2939.0 for 13" MBP Touch bar and is working as intended.

Thank you!

[Automated comment] Less than a week to go before stable on M55, we might already have a stable candidate build. Manual review required.

Your change meets the bar and is auto-approved for M56 (branch: 2924)

[Automated comment] Less than a week to go before stable on M55, we might already have a stable candidate build. Manual review required.

Thank you mark@ and  manoranjanr@ for verifying the bug on Canary. 

Approving merge to M55 branch 2883 based on comment #29 and #33.  lgrey@, please merge this change to M55 (early next week) once change is well baked in Canary and possibly in Dev.

Also would it be possible to write a postmortem for this?

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

commit bae3d81964e15c28fd5ad0ccc562e54de83a103e
Author: Robert Sesek <rsesek@chromium.org>
Date: Mon Dec 05 15:59:31 2016

[Mac] Opt browser window controller out of being a touch bar provider

Currently, on touch bar Macs, the system retains a reference to every
object it finds that conforms to the NSTouchBarProvider protocol, which
includes NSWindowController. If the user tries to quit Chrome when it
isn't foregrounded (for example, from the Dock icon context menu), these
references are never released, which means the browser window never
deallocs.

Since all browser windows being closed is a precondition of quitting,
Chrome never quits. There are a few private mechanisms to force the
touch bar to update its providers, but no matter what, the references
aren't released until Chrome is foregrounded.

This change effectively opts the window controller out of being a
touch bar provider which prevents it from being retained by the
touch bar mechanism in the first place.

BUG= 667274 

Review-Url: https://codereview.chromium.org/2550463002
Cr-Commit-Position: refs/heads/master@{#435759}
(cherry picked from commit 0098a25b70b91b23e87a4644e30722ba151e66e2)

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

Cr-Commit-Position: refs/branch-heads/2924@{#331}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/bae3d81964e15c28fd5ad0ccc562e54de83a103e/chrome/browser/ui/cocoa/browser_window_controller.mm

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

commit 102fd9dc961fc353b517c8c8ff8181f7299034be
Author: Robert Sesek <rsesek@chromium.org>
Date: Mon Dec 05 16:08:36 2016

[Mac] Opt browser window controller out of being a touch bar provider

Currently, on touch bar Macs, the system retains a reference to every
object it finds that conforms to the NSTouchBarProvider protocol, which
includes NSWindowController. If the user tries to quit Chrome when it
isn't foregrounded (for example, from the Dock icon context menu), these
references are never released, which means the browser window never
deallocs.

Since all browser windows being closed is a precondition of quitting,
Chrome never quits. There are a few private mechanisms to force the
touch bar to update its providers, but no matter what, the references
aren't released until Chrome is foregrounded.

This change effectively opts the window controller out of being a
touch bar provider which prevents it from being retained by the
touch bar mechanism in the first place.

BUG= 667274 

Review-Url: https://codereview.chromium.org/2550463002
Cr-Commit-Position: refs/heads/master@{#435759}
(cherry picked from commit 0098a25b70b91b23e87a4644e30722ba151e66e2)

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

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

[modify] https://crrev.com/102fd9dc961fc353b517c8c8ff8181f7299034be/chrome/browser/ui/cocoa/browser_window_controller.mm

Discussed with some people on the team and we're in agreement that due to the nature of the change, it's not a good candidate for a unit test, though it would certainly be desirable to have manual test coverage.

Tested the above merge (c#40) on Latest M55#55.0.2883.83 for 13" MBP Touch bar and is working as intended.

Thank you!

Thank you Mano. Please add a manual test case for this.
lgrey@, please write a postmortem for this as communicated over email.

Confirmed fixed on stable

manoranjanr@ is there a bug for the manual test? I'd like to add it to the postmortem

lgrey@: Could you please update the status to Fixed/Verified as its already verified in comment #42.

Reg c#43 & 45: Sorry for the late reply and i've added this test case as part of Chrome Mac Installers (responded in-detail over email).

Thank you!