I wasn't able to reproduce this on tip-of-tree (approximately 65.0.3317.0) in a ChromeOS build.

But this does reproduce on Mac Canary 65.0.3317.0.... and there doesn't seem to be anything relevant on a quick search of the git log.... o_O .... bizarre.....

Oh dear. It's because we don't flush the eligibility state in InstallableManager on navigation. So the HTTPS state of the first page opened by the WebContents is retained forever.

This is probably the cause of some flakiness in showing banners.... it's been as issue since https://chromium-review.googlesource.com/686079 landed (M63).

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

commit f20915ce86769a4d471f0ebedfbe49226a0c297a
Author: Dominick Ng <dominickn@chromium.org>
Date: Thu Jan 11 08:16:06 2018

Flush PWA eligibility state on navigation.

This ensures that we recheck PWA eligibility (non-main frame, secure
connection, and non-incognito) on every navigation. Some PWAs are
probably not showing banners due to this issue. However, non-PWAs
would not be detected as PWAs as service workers need a secure
connection so that check would fail later in the pipeline.

BUG= 800982 

Change-Id: I53a6edcd1778184bd50680e48714f41f3f8f7d74
Reviewed-on: https://chromium-review.googlesource.com/861550
Reviewed-by: Matt Giuca <mgiuca@chromium.org>
Commit-Queue: Dominick Ng <dominickn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528583}
[modify] https://crrev.com/f20915ce86769a4d471f0ebedfbe49226a0c297a/chrome/browser/installable/installable_manager.cc

Requesting merge to M64. This is a 1-line fix that causes our app install banner pipeline for PWAs to accidentally cache the first HTTP/HTTPS state visited by the user. The 1 line is a simple reset of a unique_ptr that mirrors other unique_ptrs set in the system.

Developers are very sensitive to flakiness in our banner pipeline (numerous bugs have been filed and it is a significant source of developer complaints at CDS, through feedback channels, etc.), so I'd like to accelerate this fix by a milestone. It's been on canary with no issues for a few days now.

This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(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/+/64de5c4745b393f306088db0e496c46c99a20adc

commit 64de5c4745b393f306088db0e496c46c99a20adc
Author: Dominick Ng <dominickn@chromium.org>
Date: Tue Jan 16 22:40:38 2018

Flush PWA eligibility state on navigation.

This ensures that we recheck PWA eligibility (non-main frame, secure
connection, and non-incognito) on every navigation. Some PWAs are
probably not showing banners due to this issue. However, non-PWAs
would not be detected as PWAs as service workers need a secure
connection so that check would fail later in the pipeline.

BUG= 800982 

Change-Id: I53a6edcd1778184bd50680e48714f41f3f8f7d74
Reviewed-on: https://chromium-review.googlesource.com/861550
Reviewed-by: Matt Giuca <mgiuca@chromium.org>
Commit-Queue: Dominick Ng <dominickn@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#528583}(cherry picked from commit f20915ce86769a4d471f0ebedfbe49226a0c297a)
Reviewed-on: https://chromium-review.googlesource.com/869070
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#514}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/64de5c4745b393f306088db0e496c46c99a20adc/chrome/browser/installable/installable_manager.cc