Hi Rebecca, the current scanning duration for WebBluetooth is 10 seconds based on the discussion at:
https://bugs.chromium.org/p/chromium/issues/detail?id=580346

And it seems that some devices take a long time on some platforms. So we now consider increasing the scan duration, for example: 20 seconds? 15 seconds?

Any suggestions? Thanks a lot!

We could also just scan indefinitely.

We talked at one point about scanning on mobile until the user switches to another app or the screen turns off. On desktop, we should probably time out eventually, but could wait several minutes.

Is there any way you could test it to determine the best number? Maybe 80% of devices are available within 20 seconds, and it's just small gains after that.

I'm open to infinite scanning too (that's what OSes do right?) but there were reasons why we didn't do that originally... Can't remember exactly and maybe they don't matter now! Did it have to do with energy resources? I vaguely remember something about helping users understand their device just wasn't present, or truncating the list at a certain point before it became unwieldy, that sort of thing.

I was primarily concerned about power use.

We could UMA the discovery time for the device users select, but only if we temporarily have a discovery time longer than the one we'll eventually pick.

OK cool. I'll check with scottj@ to see if there are any changes the physical web standard since we last discussed the 10 second cutoff.

There are a few things we need to sort out to answer this question. Is it the devices that are being missed or the platform? Nexus 5x is horrible at scanning. If the problem comes from that device, we should fix their scanning, not increase ours.

If it is not that, then the issue moves to UX issues: if you scan for 20 seconds, you're making the user wait a VERY long time, most will cancel anyway. I'd like to dig down into why this is happening before proceeding w/ a solution.

This is why, for example, the Physical Web recommends a 700ms adv packet rate. This allows you to miss one, add a 500ms round trip time to the server, and still reply to the user in <2seconds. 

ortuno, was this feature request a direct offshoot of:
 Issue 647221  bluetooth: mac: Some scanning intervals cause devices not found

I was seeing this issue so I opened the bug, then Francois figured out the cause and opened  Issue 647221 .

In discussion:
- indefinite has concerns about unbounded power consumption.
- we are currently seeing practical limitations with the current time out, e.g. when users need to reach out to a device and cause it to become discoverable

We conclude that we should just use a larger time value, such as 60 seconds, to address the practical issues while avoiding unlimited issues.

We should ensure UMA for duration and rescan selections to inform future adjustments.

CL landed:
https://codereview.chromium.org/2506163002/

We'll need to merge to 56 with Merge-Request-56 after we verify on canary. 

Your change meets the bar and is auto-approved for M56 (branch: 2924)

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

commit 18265ef5fa6076da1b5e23a7760b88ccd8140041
Author: Jun Cai <juncai@chromium.org>
Date: Mon Nov 21 18:08:25 2016

Increase Web Bluetooth device scanning duration [merge to M56]

This CL increases the Web Bluetooth device scanning duration from 10
seconds to 60 seconds. Also added UMA for the event that the re-scan
link is pressed and the duration to find at lease one Bluetooth device.

BUG=419413,  647100 

Review-Url: https://codereview.chromium.org/2506163002
Cr-Commit-Position: refs/heads/master@{#433074}
(cherry picked from commit acdbb3c267d8d4ea19d0faf4ef34b5179f3c58fa)

Review URL: https://codereview.chromium.org/2515293003 .

Cr-Commit-Position: refs/branch-heads/2924@{#29}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/18265ef5fa6076da1b5e23a7760b88ccd8140041/content/browser/bluetooth/bluetooth_device_chooser_controller.cc
[modify] https://crrev.com/18265ef5fa6076da1b5e23a7760b88ccd8140041/content/browser/bluetooth/bluetooth_device_chooser_controller.h
[modify] https://crrev.com/18265ef5fa6076da1b5e23a7760b88ccd8140041/content/browser/bluetooth/bluetooth_metrics.h
[modify] https://crrev.com/18265ef5fa6076da1b5e23a7760b88ccd8140041/tools/metrics/histograms/histograms.xml

This bug requires manual review: No test file found in commits.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), gkihumba@(cros), bustamante@(desktop)

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

This bug requires manual review: No test file found in commits.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), gkihumba@(cros), bustamante@(desktop)

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

[Automated comment] removing mislabelled Merge-Review-56, Hotlist-Merge-Review