Tried testing the issue on reported chrome version #70.0.3538.77 using Windows 10 by following below steps.

Steps:
=====
1.Launched chrome.
2.Installed a PWA app- "https://killer-marmot.appspot.com/web".
3.Navigated to Devtools->Application tab and clicked on "Add to Home screen".
4.Unable to observe any kind of errors in console.

Attached screencast for reference.
@reporter: Could you please review attached screencast and let us know if anything is being missed here. Request you to provide a sample file or URL that reproduces the issue so that it would be really helpful for further triaging of the issue. Please confirm if the issue is specific to Android.
Thanks.!

Deleted: 901352.mp4 2.0 MB

	901352.mp4 2.0 MB View Download

Hello mukkala, good night.

Thanks for the feedback. Great this app for testing!

I performed the steps as requested. I'm putting the link to the screencast. I also added the print of my chrome://version.

When to Android everything is working properly. This issue only happens with Chrome Desktop.

Screencast Link - https://share.vidyard.com/watch/EPixpArveX78X53rhXy9U9?

If you need anything else, please write.

Deleted: version.png 194 KB

	version.png 194 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

When enabling auto install mode in Killer Marmot: Web app we received another error message, see:

Screencast Link - https://share.vidyard.com/watch/TLdG36d5rQFeaQxeTqgJQv?

About the URL for your tests - https://account.c37.co, is that I am not able to perform the installation.

Able to reproduce the issue on chrome version# 70.0.3538.77 and on latest chrome# 72.0.3608.0 using Windows-10. We will provide bisect information and other OS behavior soon. Hence adding Needs-Bisect label and marking it as Untriaged.

Thanks.

Able to reproduce the issue on reported version 70.0.3538.77 and latest chrome 72.0.3608.0 using Windows-10, Mac 10.12.6 and Ubuntu 14.04 hence providing Bisect Info

Bisect Info:
================
Good build: 69.0.3497.33
Bad build: 69.0.3497.34

Issue break is seen on 69.0.3497 branch builds, hence providing below Bisect info (change log) from Omahaproxy
Change Log: https://chromium.googlesource.com/chromium/src/+log/69.0.3497.33..69.0.3497.34?pretty=fuller&n=10000
Suspecting: https://chromium.googlesource.com/chromium/src/+/8fa1bd18f23da65bfd9bf4b6a3903421fc6e9043 from above change log
Change-Id: Iee7dfc76401e7141707b2d7b2e6ac5e24297ac4b
Reviewed-on: https://chromium-review.googlesource.com/1158305

@Dominick Ng: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!

The button is actually working, it's just that the behaviour changed in M70 with the launch of desktop PWAs. This button only sends the beforeinstallpromptevent now, you need a handler for the event to trigger A2HS. See https://developers.google.com/web/updates/2018/06/a2hs-updates for more info.

We've been trying to work out a better way of surfacing this change, but haven't come to a conclusion yet. See Issue 891589.

As per DevTools triaging policy, assigning this so that it is not lost.

Given the discussion on issue 891589, I don't think it's appropriate for this issue to be assigned to me.

Screenshot with the patch applied.

Deleted: manifest.png 20.8 KB

	manifest.png 20.8 KB View Download

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

commit 6c30be45d7e9bd4a1f896d2906af9ccc2eb867cf
Author: Pavel Feldman <pfeldman@chromium.org>
Date: Tue Dec 11 01:04:22 2018

DevTools: surface the PWA installability warnings in the manifest view.

Bug:  901352 
Change-Id: Ide68cbab11d9599d3fe59aef274f12f429df346f
Reviewed-on: https://chromium-review.googlesource.com/c/1370371
Commit-Queue: Pavel Feldman <pfeldman@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#615357}
[modify] https://crrev.com/6c30be45d7e9bd4a1f896d2906af9ccc2eb867cf/third_party/blink/renderer/devtools/front_end/resources/AppManifestView.js

There is no need to trigger the 'Add to homescreen' in order to test installability of the PWA anymore. Manifest is getting proactively validated and warnings are surfaced in the Manifest view. When there are no warnings, user should expect beforeinstallprompt to be dispatched on Desktop and mini-installer to pop up on Mobile.

Able to reproduce the issue on chrome reported version# 70.0.3538.77. Tried verifying the fix on Windows-10, Mac 10.12.6 and Ubuntu 17.10. Fix is working as excepted on Ubuntu 17.10(i.e., able to see beforeinstallprompt), but on Windows-10 and Mac 10.12.6 seeing the error message(prompt() rejected: NotAllowedError: The prompt() method must be called with a user gesture)

@Pavel Feldman: Please find the attached screencast(Windows) and screenshot(Linux) for your reference and provide your confirmation on Mac and Windows OS.

Thanks!

Deleted: 901352.png 151 KB

	901352.png 151 KB View Download

Deleted: 901352.mp4 1.8 MB

	901352.mp4 1.8 MB View Download

Thanks for the fix. However, it's undesirable to reimplement the installability check in JavaScript rather than using the actual checking code in Chrome. For instance, keep.google.com is *not* installable because it doesn't have a service worker. However, it has a manifest which is valid for installation, so there are no warnings surfaced in DevTools for installability. The claim in #17 that "When there are no warnings, user should expect beforeinstallprompt to be dispatched on Desktop" is not true. DevTools is now in fact misleading developers with this change applied (see attached from Canary with the patch applied. No beforeinstallpromptevent has been sent).

The way this is implemented is a maintainability burden as well since we're planning to change the check in C++ soon, and then we have to try and parallelise those changes in DevTools as well. Ideally, DevTools should just use Chrome's existing check here. That way, we maintain our check and it stays up to date in devtools without needing any extra work.

I can help with allowing the installability checking code in Chrome to report up to DevTools what errors actually occurred, but I don't know how the plumbing to DevTools needs to work, so if we can work together on that we can make improvements here.

Deleted: Screen Shot 2018-12-14 at 12.02.44.png 361 KB

	Screen Shot 2018-12-14 at 12.02.44.png 361 KB View Download

>> For instance, keep.google.com is *not* installable because it doesn't have a service worker

Could you file a separate bug on this along with the expected results and actual behavior?

>> The way this is implemented is a maintainability burden as well since we're planning to change the check in C++ soon, ...

The current validation in DevTools is 4? lines of code, I'm sure we can keep it in line with the spec / documented behavior every time it changes. See more on it below.

Every time we change that C++ check, all the developers in the world need to update their sites. I'm sure we can coordinate messaging to the developers along with the documentation and updates to our devtools.

>> I can help with allowing the installability checking code in Chrome to report up to DevTools what errors actually occurred, but I don't know how the plumbing to DevTools needs to work, so if we can work together on that we can make improvements here.

The plumbing is automatically generated, you don't need to think about it. Follow the "requestAppBanner" that we used for it previously. Note though, that in order to preserve current ergonomics, it would need to return warnings over the protocol. Do you mind filing a separate bug for it?

I have filed  Issue 915943  to track the inaccuracy of the existing DevTools check. That issue lists a number of checks off the top of my head that the DevTools installability check implementation omits.

I have filed Issue 915945 to track the improved plumbing.