Tested the issue on Android and unable to reproduce this issue. 

Steps followed:
1. Launched chrome , navigated to app-stg.diagfactory.com and registered user
2. On logging in, this is showing invalid credentials though we gave correct credentialss.

Chrome versions tested:
70.0.3501.0(Canary)

OS:
Android 9.0

Android Devices:
Pixel 2 XL

matthieu.dambrune@: Please provide alternate URL/ test credentials to test this issue . Also could you please let us know if this issue is consistently reproducible? Any further information on reproducing the issue would help in better triaging.

Thanks!

Register process works as expected but on this environment data are resetted every day at 1ham UTC

Anyway you can use these credentials:
user: diaguser2@yopmail.com
pass: diagpass

1 - go on app-stg.diagfactory.com
2 - mini-infobar should appear immediately /!\
2 - log in
3 - open the side menu
4 - Click on the green button (it just calls BeforePromptInstallEvent.prompt())
5 - The install dialog should appear, click on the black background to close it
6 - Click again on install button, nothing happens /!\

Even if the user click on the install button and explicitly decline or dismiss the dialog. Call to .prompt() should show the install dialog again.
.prompt() should be disabled only if the userChoice is "accepted"

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

From the spec https://www.w3.org/TR/appmanifest/#beforeinstallpromptevent-interface :
If the BeforeInstallPromptEvent is not cancelled, the user agent is allowed to present an automated install prompt to the end-user. Canceling the default action (via preventDefault) prevents the user agent from presenting an automated install prompt

-> BeforePromptInstallEvent.preventDefault() has no effect on mini-infobar for now

Well, for the mini-infobar issue, it seems it's expected that developer cannot prevent it... https://github.com/w3c/manifest/issues/691#issue-332248820

Note:
After a first call to prompt method:
- If the a2hs dialog is dismissed with a click on the `cancel` button inside the dialog, a new call to the prompt method reopen the a2hs dialog (expected)
- If the a2hs dialog is dismissed with a click outside the dialog itself, a new call to the prompt method does not reopen the a2hs dialog (unexpected)

Device back button & click on background overlay have the same issue

That said:
1 - The same action should be executed for every dismiss method (click on background overlay, device back button, cancel button)
2 - The a2hs dialog shouldn't be closable until the user click on dialog button (cancel/accept)

Tested the issue in Android and able to reproduce the issue. 

Steps Followed:
1 - Launched chrome, navigated to app-stg.diagfactory.com
2 - mini-infobar >> appeared immediately 
2 - logged in with sample creds
3 - opened the side menu
4 - Click on the green button -- install dialog appeared, clicked on the black background to close it
6 - Click again on install button -- now dialog is not seen again after closing in background


Chrome versions tested:
67.0.3396.87 , 70.0.3503.0(Latest canary)

OS:
Android 9.0

Android Devices:
Pixel 2 XL

Using the per-revision bisect providing the bisect results,
Good Build - 67.0.3389.0
Bad Build - 67.0.3390.0 

Culprit: https://chromium.googlesource.com/chromium/src/+/e81fab496202e46b7f3834d418520c7750014918

@ dominickn: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to owner concerned. 

Please navigate to below link for log's  --
go/chrome-androidlogs/867465


Thanks!

NOTE: 
=====
In build #67.0.3389.0 -- we are observing pwa dialog at bottom of page and on clicking out of that dialog doesn't dismiss it.

Where as from build #67.0.3390.0 -- observing PWA dialog as separate and on clicking outside it, dialog is dismissed and is not appearing even after clicking it again.

Hence considered #67.0.3389.0 as good build and #67.0.3390.0 as bad.

Thanks!

Hmm, looks like we're not refiring beforeinstallprompt if the user clicks outside the dialog. beforeinstallprompt *is* being refired if you hit "cancel" on the modal dialog, but not when you touch outside.

@mattieu, can you confirm that? I'll look into a fix next week.

Oops, accidental status change.

@dominickn yes, that is exactly what's going on

#13: thanks. I will follow up with a fix (should be straightforward) next week.

CL awaiting review: https://chromium-review.googlesource.com/c/chromium/src/+/1157945

> This CL addresses an inconsistency in behaviour between explicitly
tapping "Cancel" in the add to home screen dialog and tapping outside
the dialog to dismiss it

@dominickn just to be sure the issue will be fully fixed, "tapping outside the dialog" include device back button ?

Yes, it will cover any way that the dialog would be dismissed as long as the user didn't add to home screen.

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

commit 41b2c8411252a1527f7c32b93a9052f1c3ec77f1
Author: Dominick Ng <dominickn@chromium.org>
Date: Fri Aug 03 22:56:36 2018

Combine AddToHomescreenDialog.Delegate#{onDialogCancelled(),onDialogDismised()}.

This CL addresses an inconsistency in behaviour between explicitly
tapping "Cancel" in the add to home screen dialog and tapping outside
the dialog to dismiss it (also effectively cancelling).

Explicitly tapping on "Cancel" allowed the site to receive a new
beforeinstallpromptevent to trigger a new dialog, but tapping outside
the dialog did not. This CL removes the inconsistency by eliminating the
AddToHomescreenDialog.Delegate#onDialogCancelled() method (previously
only called when explicitly tapping "Cancel"), and maintaining state in
the AppBannerUiDelegateAndroid to determine whether or not to call
AppBannerUiDelegateAndroid#nativeOnUiCancelled(). This ensures a fresh
beforeinstallpromptevent is dispatched when the dialog isn't accepted -
whether it was explicitly cancelled or implicitly dismissed by tapping
elsewhere on the screen.

BUG= 867465 

Change-Id: I4e37d4a34e2b25797ee5bc386010de0b995e3d93
Reviewed-on: https://chromium-review.googlesource.com/1157945
Commit-Queue: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580685}
[modify] https://crrev.com/41b2c8411252a1527f7c32b93a9052f1c3ec77f1/chrome/android/java/src/org/chromium/chrome/browser/banners/AppBannerUiDelegateAndroid.java
[modify] https://crrev.com/41b2c8411252a1527f7c32b93a9052f1c3ec77f1/chrome/android/java/src/org/chromium/chrome/browser/webapps/AddToHomescreenDialog.java
[modify] https://crrev.com/41b2c8411252a1527f7c32b93a9052f1c3ec77f1/chrome/android/java/src/org/chromium/chrome/browser/webapps/AddToHomescreenManager.java

This should be fixed in the latest Chrome Canary release.