Could we also badge in the UI that these websites are no longer "nearby"?

Unfortunately icons have a very poor user testing track record of actually conveying the correct meaning (after repeated use, yes, they can work, but not on a single exposure) 

However, there are viable alternatives. Matt suggested something like a toast that spells it out e.g. "This website was found 30 minutes ago" This much more direct and clear.

Yes, I think a toast makes a ton of sense here.

Should we plan to do this for M52?

I like this suggestion, but as Scott says, is predicated on us beginning to cache metadata on the client.  We don't do this today, and we should think through how we want to add this.

I suspect we could do it quickly to address just this one use case, or we could take time to solve it more completely to address many use cases.

This bug likely ties into the 'better swipe behavior' bug. If we cache things for one bug, we can use it for the other.

The easiest strategy is to remember a single URL:

1. Cache a single URL, the first onFound that triggered the notification

2. Cache a single URL, the last onLost that caused the notification to be dismissed

If we want to remember more than a single URL the logic gets more complicated.

3. Cache the list of all nearby URLs each time we get onFound or onLost.  The downside is when we need it the list will only ever have one URL -- the last onLost we received.  This is essentially the same as option 2.

4. Cache the list of all nearby URLs each time we get onFound (only).  This is more likely to remember more URLs, but we'll still potentially lose URLs based on the order we receive onFound/onLost events.  Ideally, the order shouldn't make a difference in the number of displayed URLs.

5. Append nearby URLs to the cache when we receive onFound, but don't remove them for onLost.  This would never lose URLs but the list could grow very large and could potentially contain URLs that were discovered several hours or days ago, so we would likely want a hard limit on the size of the cache.

6. Append timestamped nearby URLs to the cache when we receive onFound, remove them after some reasonable timeout.  For instance, each time we add to the cache we could also drop all URLs that were found more than X minutes ago.

I think any of these would be a reasonable solution for the onboarding case, but options 5 or 6 would give us the most complete results if we eventually decide to implement this as a "recently nearby URLs" feature outside of onboarding.

I just want to add that the UX motivation here is to show a 'non-empty' results list. The idea of >1 results is nice but likely a slippery slope as it's not even clear you saw all of these beacons at the same time.

Just wanted to remind people that even having a single URL is actually very useful. If having >1 is harder/riskier, it's worth considering keeping with just the one.

I do think it makes sense to implement this outside of onboarding as well, eventually just as something in the list of results (e.g. "URL was last found at X"). How much more complexity would it be to do 5 or 6?

Matt, recall that this is mostly meant to handle the case where we didn't get onLost events (can happen if scan isn't active while you move out of range).

Therefore I think your (3) would actually give the last known list of nearby URLs.

For now, I think just 1 value would be fine.  I suggest that URL should be the most-recent-found (override the last value on each new onFound).

I think (5) is where we should strive to get eventually.

For (6) we could just clear the cache every time we clear the onboarding Notification (once all beacons are lost or we timeout).

Also note that we already track the list of URLs for (3), but we clear this value on Chrome startup, and we don't get it back when we start a new BT scan.

Perhaps the easiest fix is to not clear the list on startup, but move it to a last-known list?

Agreed with starting with (3) and then eventually moving to (5) 

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

commit 14e576fc9a0dfcfc7e4b49520476cd4079c0cd3e
Author: cco3 <cco3@chromium.org>
Date: Wed May 11 20:56:05 2016

Test Physical Web upgrade path

We used to use a specific SharedPreference file, now we use the common
one.  This change tests the upgrade path.

BUG= 597316 

upgrade

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

[modify] https://crrev.com/14e576fc9a0dfcfc7e4b49520476cd4079c0cd3e/chrome/android/java/src/org/chromium/chrome/browser/physicalweb/UrlManager.java
[modify] https://crrev.com/14e576fc9a0dfcfc7e4b49520476cd4079c0cd3e/chrome/android/javatests/src/org/chromium/chrome/browser/physicalweb/UrlManagerTest.java

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

commit fe8947ed378f5a0ba7c602dbae38864d73a6b0f1
Author: cco3 <cco3@chromium.org>
Date: Thu May 12 21:04:48 2016

Use polling to test Physical Web upgrade path

Our upgrade test is failing on some devices.  It could be a race
condition that makes waitForIdleSync insufficient.  If this is
indeed the issue, using CriteriaHelper should fix the problem.

BUG= 597316 

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

[modify] https://crrev.com/fe8947ed378f5a0ba7c602dbae38864d73a6b0f1/chrome/android/javatests/src/org/chromium/chrome/browser/physicalweb/UrlManagerTest.java