Not clear to me whether it's an app banner issue or webapk issue. Assigning to Dominick to triage.

I won't have time to look at this until later in the week, but it seems bad. For now, clarifications:

1. "Clicked but did not install". Did you dismiss the dialog by tapping elsewhere on the screen?
2. Is step2 screenshot what you had prior to visiting progressivewebflap.com?
3. 57.0.2977.4 is a very old version of dev, with the last commit landing 3 weeks ago. I'm not even sure it's WebAPK-capable; did you manually enable WebAPKs?

#2:

1. Yes, I would've dismissed by tapping elsewhere. I'm a bit fuzzy on exactly what I did because the not-installing-washpost issue was about half an hour before the trying-to-install-webflap.
2. No, Step 2 screenshot is immediately after clicking the Install button you see in Step 1. You can see the PWF website and PWF install banner in the background.
3. It might be a bit old. I have turned on the flags enable-improved-a2hs and bypass-app-banner-engagement-checks, so that might be contributing to the weirdness.

Another thing I noted is that the banner you see in Step 1 *is* the Android app banner (not the WebAPK banner). There is no Progressive Web Flap app in the play store. The 4.5 stars is for Washington Post. It's a WashPost Android app install banner except that it has the wrong icon and title.

I'm trying to repro now. Note that I could *still* repro hours later by going to progressivewebflap.com and waiting for the install banner. But then I restarted Chrome and now I can't seem to trigger it again. (I get the WebAPK install banner.) Same Chrome version.

I tried... a lot. Cannot reproduce :(

Now on 57.0.2987.9. Still cannot reproduce (though that doesn't mean it's fixed; since I also couldn't repro on the same version as I initially experienced).

#3: Sorry, you said in your repro that you initially went to washingtonpost.com and got their Android app install banner. This is what I meant by asking whether the step 2 screenshot was also what you had in step 1 (except washingtonpost.com in background with a washingtonpost Android app banner - apologies for lack of clarity).

Without a repro case it will be difficult to pin this down. Navigation should clear all banner state.

Perhaps the 30 mins lag time is important here (Android backgrounding / killing Chrome, and the state restoration also does something weird with the data caching such that the native app data isn't flushed, but the web app data is flushed and populated with the progressivewebflap.com data).

Still can't reproduce.

I opened WashPost and PWF in two tabs. Triggered the native app banner for WashPost and clicked Install, then cancelled. Then I went off and opened other apps, switched profiles and back, until I was sure Chrome was killed (when I reopened it it took a long time to show tabs). Switched immediately to PWF and got the web APK install banner.

Not sure what else to try.

Using two different tabs might make this not reproduce - separate tabs have separate AppBannerManagers and hence will have different banner caches in memory. I think that you'd need to have the same tab to be able to trigger this (was the original repro just in one tab, or in multiple?)

Ah yeah you're right. Repro'd it!

1. Turn on enable-improved-a2hs and bypass-app-banner-engagement-checks flags.
2. Open https://www.washingtonpost.com in the *only* tab.
3. Have Chrome killed by Android (I switch profile, open Chrome in that profile, then switch back and open Chrome again).
4. Open Chrome again.
5. Navigate the same tab to https://www.progressivewebflap.com.

Shows the Google Play install banner with 4.5 stars, and clicking Install triggers the Washington Post Android app install flow.

This is now on Chrome 57.0.2987.9.

Thanks so much for the extensive debugging work here! :)

I'll investigate this ASAP - meanwhile this should block WebAPK launch. It must be some weird caching / data restore issue after Chrome is killed by Android and then restarted.

I reproed this too but without switching profile or killing Chrome. Here is what I did

1) Navigate to washingtonpost.com
2) Tap "Install" when the banner for "The washington post" shows up
3) Tap back when the "Google Play Install" dialog shows up
4) Navigate the same tab to https://www.progressivewebflap.com 

For the sake of completeness, I used Chrome Beta to repro which is old (I think still 56)

I just talked to Dominick and he said he would likely not have time to look into this bug today. I have the time so I will give this bug a shot :)

It seems like AppBannerManagerAndroid::native_app_data_ is never cleared. In AppBannerManagerAndroid::ShowBanner() we check whether AppBannerManagerAndroid::native_app_data_ was set in order to determine the type of banner

Right. The fix should be to call native_app_data_.Reset() in DidFinishNavigation.

CL is up at https://codereview.chromium.org/2671653002/

Simplified test steps
1) Enable "Bypass user engagement checks" in chrome://flags
2) Navigate to mapquest.com
3) Notice that an "Install" infobar should shows up. It has an "Install" button and is rated 4/5 stars
4) Navigate to https://www.progressivewebflap.com
Test that the web app infobar shows up. The infobar should have an "Add to home screen" button and not have any stars

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

commit de6f8b587176d94643869d0f28aee52b92ad00b8
Author: pkotwicz <pkotwicz@chromium.org>
Date: Mon Feb 06 07:03:18 2017

Webapps: Clear AppBannerManagerAndroid::native_app_data_ prior to native app check

This CL fixes a bug where
1) Navigating to a web page which has a Web Manifest with
"related_applications" specified.
2) Navigating to a web page with a web app compatible Web Manifest
would show a native app banner for the second page.

Whether |AppBannerManagerAndroid::native_app_data_| is set is used to determine
which type of banner to create (native app or webapp). Previously
|AppBannerManagerAndroid::native_app_data_| was only cleared if there was a
native app associated with the Web Manifest. This CL clears
|AppBannerManagerAndroid::native_app_data_| prior to checking
whether there is a native app associated with the Web Manifest.

BUG= 687024 

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

[modify] https://crrev.com/de6f8b587176d94643869d0f28aee52b92ad00b8/chrome/browser/android/banners/app_banner_manager_android.cc
[modify] https://crrev.com/de6f8b587176d94643869d0f28aee52b92ad00b8/chrome/browser/android/banners/app_banner_manager_android.h
[modify] https://crrev.com/de6f8b587176d94643869d0f28aee52b92ad00b8/chrome/browser/banners/app_banner_manager.cc
[modify] https://crrev.com/de6f8b587176d94643869d0f28aee52b92ad00b8/chrome/browser/banners/app_banner_manager.h

Requesting to merge  https://codereview.chromium.org/2671653002/ to M57

The CL has made it to 58.0.3007.3 Chrome Canary

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

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

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

commit 6403b796f661a1dbf0daf3825ff737d366ddea7f
Author: Peter Kotwicz <pkotwicz@google.com>
Date: Fri Feb 10 21:16:04 2017

Webapps: Clear AppBannerManagerAndroid::native_app_data_ prior to native app check

This CL fixes a bug where
1) Navigating to a web page which has a Web Manifest with
"related_applications" specified.
2) Navigating to a web page with a web app compatible Web Manifest
would show a native app banner for the second page.

Whether |AppBannerManagerAndroid::native_app_data_| is set is used to determine
which type of banner to create (native app or webapp). Previously
|AppBannerManagerAndroid::native_app_data_| was only cleared if there was a
native app associated with the Web Manifest. This CL clears
|AppBannerManagerAndroid::native_app_data_| prior to checking
whether there is a native app associated with the Web Manifest.

BUG= 687024 

Review-Url: https://codereview.chromium.org/2671653002
Cr-Commit-Position: refs/heads/master@{#448218}
(cherry picked from commit de6f8b587176d94643869d0f28aee52b92ad00b8)

Review-Url: https://codereview.chromium.org/2695473002 .
Cr-Commit-Position: refs/branch-heads/2987@{#452}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/6403b796f661a1dbf0daf3825ff737d366ddea7f/chrome/browser/android/banners/app_banner_manager_android.cc
[modify] https://crrev.com/6403b796f661a1dbf0daf3825ff737d366ddea7f/chrome/browser/android/banners/app_banner_manager_android.h
[modify] https://crrev.com/6403b796f661a1dbf0daf3825ff737d366ddea7f/chrome/browser/banners/app_banner_manager.cc
[modify] https://crrev.com/6403b796f661a1dbf0daf3825ff737d366ddea7f/chrome/browser/banners/app_banner_manager.h

 Issue 698483  has been merged into this issue.

Lifting RVG.