What device model are you using?

Nexus 5X

Friendly ping - any updates on this? Have you been able to reproduce it?

Add to home screen -> Dominick.

I can't reproduce this, except if I enable chrome://flags/#bypass-app-banner-engagement-checks. Are you absolutely sure that flag is disabled on your test device? That should be the only way that you see a banner again and again and again.

In any case, you do have control over the banner - you can add a listener for the 'beforeinstallprompt' event, and call preventDefault() on it. See https://developers.google.com/web/fundamentals/engage-and-retain/app-install-banners/advanced under "Deferring or Cancelling the Prompt"

Yep, I'm sure it's not turned on. And I can reproduce it quite easily. Are you using a Nexus 5X?

I've tested using both a Nexus 5 and a Nexus 5X, both with Chrome 53.0.2785.124. I also tried Chrome Beta with the same results on the Nexus 5. In all cases, the banner came up once, then after refreshing the page and long-pressing to get coordinates, I couldn't get the banner to trigger again.

hmm not sure then. Is there anything you'd like me to do on my phone to debug?

Can you try a fresh profile? Or if you don't mind nuking everything, try Menu -> Settings -> Privacy -> Clear Browsing Data, then loading the page afresh after restarting Chrome (both of those should reset the banner counters)? You can also try checking your site on other phones that you or people you know have to see if you can reproduce it elsewhere. Or you can install Chrome Beta/Dev and see if it reproduces in either of those.

Failing that, I'm not sure what else we can do. Your phone is really acting like that bypass flag is on, which is very strange since it's not on. Metrics seem to suggest that we don't have a widespread overtriggering problem. The only other theories I have are much more out there - maybe Chrome isn't correctly persisting prefs, so the fact that a banner is shown isn't being picked up, or the like.

And like I mentioned in comment #6, you can add a tiny bit of JS to your page to catch the beforeinstallprompt event and call preventDefault() on it. That will always prevent the banner from being shown.

The JS would totally work to solve my problem, so thanks for that. But I'm more concerned about the underlying reason; which is why I dont want to nuke the phone or reset it: we'd lose the ability to reproduce this.
I'll see if I can find people around me to test this and see if I can reproduce it on those phones, and I'll update this bug with my findings

Thanks for the help - keep me posted on what you find and I'll update the bug if I have any brainwaves. :)

Thank you for providing more feedback. Adding requester "kravula@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

We just took a look at this in person and identified the following:

- The banner shows in response to some taps, presumably incrementing site engagement score
- The banner shows even when the site is added to the home screen
- The banner shows even after it has been dismissed previously
- The site currently has 34 site engagement score on the repro device
- The site has enabled the persistent storage origin trial

I hope the fact that both the home screen check and previously dismissed check are failing helps narrow down what could be causing this

I'm pretty sure the only reason why the home screen check and previously dismissed checks should be "failing" is if the bypass app banner engagement checks flag is active (or something is fundamentally wrong with content settings on this device). The behaviour you're describing is precisely what happens when that flag is on. I simply can't reproduce the behaviour you're seeing without turning on the flag.

I'm skeptical that the persistent storage origin trial is affecting things, but I can investigate to see. As far as I know there's no interaction between that and app banners.

Is it possible that your device is running a custom command line to launch Chrome? Even if chrome://flags shows the bypass flag is off, it might be that your command line launching Chrome contains --bypass-app-banner-engagement-checks.

Can you check chrome://version and let me known what flags are displayed, and also what "Variations" are present? This is quite a mystery.

My phone is an off the shelf phone (ie not internal/dev/dogfood/etc). And chrome is the default chrome that comes with the device; nothing fancy. (And it's version 53)

I've copied all flags from the chrome://flags page and added them to the attached flags.txt. As you can see (although the layout of the txt file is a bit crap), the bypass flag is off.

Deleted: flags.txt 35.2 KB

flags.txt 35.2 KB View Download

Can you please check chrome://version (not chrome://flags) let me know what flags are displayed there, and also what "Variations" are present.

Sure thing, here you go:


Google Inc.
Copyright 2016 Google Inc. All rights reserved.
Google Chrome	53.0.2785.124 (Official Build) (32-bit)
Revision	7f5781e9210f9b7c8914adbc018590eec1ede150-refs/branch-heads/2785@{#902}
OS	Android 7.0.0; Nexus 5X Build/NRD90R
Blink	537.36 (@7f5781e9210f9b7c8914adbc018590eec1ede150)
JavaScript	V8 5.3.332.45
User Agent	Mozilla/5.0 (Linux; Android 7.0; Nexus 5X Build/NRD90R) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.124 Mobile Safari/537.36
Command Line	--use-mobile-user-agent --use-mobile-user-agent --enable-begin-frame-scheduling --enable-pinch --enable-viewport --enable-overlay-scrollbar --validate-input-event-stream --enable-longpress-drag-selection --touch-selection-strategy=direction --disable-gpu-process-crash-limit --main-frame-resizes-are-orientation-changes --disable-composited-antialiasing --ui-prioritize-in-gpu-process --profiler-timing=0 --prerender-from-omnibox=enabled --enable-dom-distiller --flag-switches-begin --flag-switches-end --top-controls-show-threshold=0.5 --top-controls-hide-threshold=0.5 --enable-instant-extended-api
Executable Path	No such file or directory
Profile Path	/data/user/0/com.android.chrome/app_chrome/Default
Variations	6a89113b-2bdd0794
236d5d9e-c603f8c6
47e5d3db-3d47f4f4
77207729-3d47f4f4
4bf94d2-26e7b859
4b828c6d-f23d1dea
ba3f87da-ca7d8d80
f15c1c09-ca7d8d80
1ce8a192-3f4a17df
63d6a31a-3f4a17df
6caf51ba-356a452c
10667b28-e2bc4126
93731dca-3f4a17df
9e5c75f1-dc6f1dc2
f79cb77b-3d47f4f4
b7786474-d93a0620
158a87f-3f4a17df
9e46b3e5-3d47f4f4
868bda90-ca7d8d80
4ea303a6-aa354fa2
826d6cab-96e3ef3c
8b4d89aa-31596742
4d35b2c4-21a50c70
867c4c68-3d47f4f4
3ac60855-486e2a9c
4442aae2-a5822863
ed1d377-e1cc0f14
75f0f0a0-e1cc0f14
e7e71889-e1cc0f14
dd139bd7-ca7d8d80

Any update on this bug?  Just wondering if you can manually set your site engagement for this to something like 34 and see if you can *then* reproduce it?

Manually setting the engagement to 34 doesn't reproduce the issue.

Your command line looks fine, and the variations seem fine to. I'm at a loss as to what's going on. :(

Bugs like this are just the worst...

Is there anything else that could help here? Would a trace help? Would having access to the device help?

There won't be much interesting in the trace from banners, since the logging is suppressed until you force the banner to appear with the bypass flag. I should be visiting the US mid next month, I guess seeing this in person would be good, but I can't guarantee that I'll be able to get much out of it since it won't be a debug build.

WontFixing this for now until we can get a confirmed repro case.