Can confirm last working version: 58.0.3029.110

Still an issue in: 62.0.3172.0

OS: OS X 10.11.6

I find this button super flaky too. Sometimes it just does nothing.

It's also not clear to me if I'm on macOS and haven't flipped the flag to enable A2HS whether I should expect to see anything at all.

Improving this is a P0-P1 for installability team!

While this is still not resolved. I found that simulating A2HS for desktop is also possible by following the steps. 
1) Open the webapp
2) Click the Chrome Menu 
3) Select "More tools"
4) Select "Add to desktop"
Chrome prompts to request permission to install app. 

I'll confirm if this is a replacement of the initial simulation and report back. 

 Issue 767771  has been merged into this issue.

I've found at least one source of flakiness here to do with a race condition on when the page load event finishes and when the banner flow is triggered (from devtools). CL in progress.

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

commit 0622adc1c5f32cca3c719e0eba760a5c4b161246
Author: Dominick Ng <dominickn@chromium.org>
Date: Fri Sep 22 08:51:57 2017

Address a race condition when triggering banners from devtools.

The app banner pipeline sets a flag variable checking whether or not
sufficient engagement has been achieved to trigger the banner. However,
if devtools is used to trigger the banner, the flag variable may have
never been set to true depending on when the devtools triggering
happened.

This CL addresses the race by changing the engagement check to also
consider whether or not we are in debug mode. If IsDebugMode() is true,
then we always consider there to be sufficient engagement to trigger the
banner.

BUG= 739344 

Change-Id: I55d999585e3155042b884e39d23cf557ae9d8c18
Reviewed-on: https://chromium-review.googlesource.com/677901
Reviewed-by: Peter Beverloo <peter@chromium.org>
Commit-Queue: Dominick Ng <dominickn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503693}
[modify] https://crrev.com/0622adc1c5f32cca3c719e0eba760a5c4b161246/chrome/browser/banners/app_banner_manager.cc
[modify] https://crrev.com/0622adc1c5f32cca3c719e0eba760a5c4b161246/chrome/browser/banners/app_banner_manager.h

c#7 is now live in Canary and it seems to have dramatically improved the reliability of the devtools banner triggering. Please take a look and reopen if things still seem a bit awry.

c#8 Tried that and it seems there's no more issue with that in this end. Is this going to be stable soon

I believe it'll be stable the first week of December.

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

commit fda6bb3c907a1fddba63b3e56a3f1d8565e4a2af
Author: Michael McGreevy <mcgreevy@chromium.org>
Date: Thu Nov 09 02:38:12 2017

Log a console message when a devtools-triggered app banner is suppressed

Developers using devtools to simulate add to home screen currently receive
no feedback if the site they are testing on suppresses the app banner.
This can make it seem like the devtools functionality is flaky. This CL adds
console logging for this situation, to help developers understand why the
install banner has been suppressed.

Bug:  739344 
Change-Id: Iaebbee3a6b7e01b0956112d9bdcf42043b179128
Reviewed-on: https://chromium-review.googlesource.com/743141
Commit-Queue: Michael McGreevy <mcgreevy@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#515067}
[modify] https://crrev.com/fda6bb3c907a1fddba63b3e56a3f1d8565e4a2af/chrome/browser/banners/app_banner_manager.cc