New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 10 users

Issue metadata

Status: Fixed
Closed: Feb 2015
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug

issue 459839

Sign in to add a comment

Update native / web app install banner triggering

Project Member Reported by, Jan 28 2015

Issue description

- the banner should trigger iff:
  - the site has met some criteria of visits (e.g. on a previous day in the past two weeks)
  - the banner hasn't been shown recently (or maybe ever for a first cut)
  - the app isn't installed / added to homescreen (or some approximation of this.)

Also, for the first cut we'll probably prioritize the web app install banner over the native app install banner.
Blocking: chromium:452566
Also, the banner should trigger only if some quality level is met. Code for this quality level is coming from someone else (is there a bug for that?).

Comment 3 by, Jan 28 2015

I'm hoping/anticipating that Alex will coordinate that other code, perhaps with help from Tokyo, although I've not actually heard anyone commit yet.

Also hopefully Alex R's new doc clarifies these rules a little if they were a bit vague before. He'll probably suggest we don't punt allowing the developer to indicate priority in the manifest, so its something to bear in mind as you finish up the other triggering logic.

For reference, here is a doc outlining what we'll do: (Google only).

Currently there are still a lot of things to figure out but I'll make assumptions.

Thinking about this overnight I am now planning to not use history at all, but to add extra information into app banner content setting dictionary we currently have.

This currently has information per android package, I'd like to treat web app start URLs as package names. That is, we'd have information for each origin about andriod packages and web app start URLs like:
- user has blocked this package / manifest
- separate instances when the package / manifest banner could have been shown [1]
- instances when the package / manifest banner was dismissed.

Let me know if this doesn't seem reasonable.
You'll probably want to loop in the people on that email I sent you RE:the ContentSetting dictionary.  I think one of the reasons they originally objected to adding things to the dictionary in the first place was because the whole thing resided in memory.

Comment 7 by, Jan 29 2015

It seems that turned out not to be a problem. Quoting Bernhard: "Storing complex data in content settings is absolutely fine" (ref:
Project Member

Comment 8 by, Feb 3 2015

The following revision refers to this bug:

commit 1fa5a3081a04c314c2dcdf8afc6b9d951be13493
Author: benwells <>
Date: Tue Feb 03 04:13:14 2015

Update content setting for app banners to store more information.

This changes the app banner content setting from being a dictionary of
app key to bool, to being a dictionary of app key to dictionary.

The sub dictionary contains one bool for whether the banner has been
blocked, and also a list of dates. The list of dates will contain at
most 14 dates, and will be used to record distinct dates on which the
banner could have been shown.

This is to allow more complex triggering. The goal is to actually show
banners if they could otherwise have been shown on a previous date in
the last 14 days.

Note the complex triggering is not currently used.

BUG= 452825 

Review URL:

Cr-Commit-Position: refs/heads/master@{#314266}


Project Member

Comment 11 by, Feb 7 2015

The following revision refers to this bug:

commit e7020ca28ac9bc1960f824beeeabff85db333131
Author: dfalcantara <>
Date: Sat Feb 07 12:30:38 2015

Move banner counting logic much later in the pipeline

The banner can fail to be shown for any number of reasons,
from a user navigation to a failed icon fetch.  Record that
the banner could have been shown only right before the
infobar is created.

This fixes situations where a user already had a native app
installed and the website requested a banner for it, which
permanently fills a slot in app dictionary for the site --
even if the Play Store tells the AppBannerManager that the
app is installed and no banner should be shown.

BUG= 453170 , 452825 

Review URL:

Cr-Commit-Position: refs/heads/master@{#315193}


Status: Fixed
Marking this fixed - remaining tasks are tracked in separate bugs.
Blocking: -chromium:452566
Blocking: chromium:459839

Sign in to add a comment