rkc mentioned on the other bug that maybe the right fix for advertisement spam is in BlueZ? I'm not familiar with bluetooth, so he's a better person to ask than me.

If bluez can control update rates, it's probably simpler to have the code rebuild all the views each time.

If bluez can't control the rate, or we think there are real-world non-attack use cases where the view would update frequently, then adding per-device updates seems OK.

I also thought that's steven has a good point that users can't really cope with a list (like the Wi-Fi list) that updates more often than once a second, so throttling seems useful too.

Unlike WiFi, where the strongest AP is often the one you care about, with Bluetooth devices, a user may be interested in several devices, at times ones not the closest one to them (for example, they could be pairing with speakers, but their phone may be closer).

Hence we really want to show the top 10-20 devices next to the user very quickly; taking 20s to do that seems like a poor user experience.


I would still like to have us fix this code - because even though we will limit the total number of devices from BlueZ, the rate at which they come through may be fairly fast. It also seems to be the more correct thing to do.

I wasn't proposing adding items one at a time. I imagined some lower layer of the stack (in chrome) would maintain the full list of devices. When you open the detailed menu it would show the full list of everything it knows about. Then 1 second later it would rebuild the UI with the new full list. etc. No latency up front, just throttle the refreshes.

I'm not opposed to doing incremental updates to the views, it just adds UI code complexity and I'd like be sure we really need to do it.

Rate limiting the refresh of the full UI also seems reasonable. Both add complexity, the rate limiting seems to be more future proof.

Can we also limit the number of devices we add to the view? That way even if we do end up somehow getting flooded with devices, we will only show the last 50-100 or so of them, hence hopefully not causing the memory issue. We could limit them in the settings page too.

That should solve the problem (though we should still look at sanity checking total devices in BlueZ) without letting the devices that Chrome holds versus BlueZ holds going out of sync.

Hi, I added a alternative proposal based on the suggestions above:
1. Limit number of devices shown in the bluetooth UI (bluetooth tray and bluetooth setting).
2. Rate limiting the refresh of the bluetooth tray.

Note this is special treatment for UI in case of an attack, device list in bluez layer and device/bluetooth layer should be still in sync.

Details: https://docs.google.com/a/google.com/document/d/1vnhaOJ484q_fWHYZSDvwfeOlO9Oz6XdH6sI1BFjcwyg/edit?usp=sharing#bookmark=id.23nhv95m48o5

Please let me know if you have some concerns/comments.

The fix is landed at UI layer: https://chromium-review.googlesource.com/c/chromium/src/+/765014