When a device causes a page to open, the page should be able to find the device

[jyasskin]

For example, an Eddystone-URL beacon can cause the browser to suggest a user visit a particular web page. If the user does, that page could get direct access to the device instead of needing to go through the requestDevice() chooser.

Sketch at https://docs.google.com/document/d/1jFCTyq84T2fLc8ZhxorTz3u_gCk59hp17EmkFgaDQ2c/edit?usp=sharing.

[markafoltz]

Thanks for the document @jyasskin, that explains pretty well what I was thinking of regarding the question I asked at yesterday's F2F.

FWIW I like the approach using navigator.bluetooth.referringDevice, as it makes the page initialization code pretty clean. Also things appended to the URL might get lost or munged during redirects.

if (navigator.bluetooth.referringDevice) {
  connectToServices(navigator.bluetooth.referringDevice);
} else {
  connectDeviceButton.onclick = function() { navigator.bluetooth.requestDevice()
      .then(connectToServices); };
}

[jyasskin]

Before we can do this, we need to ensure it doesn't make it really easy for a hostile physical-web device to get paired as a keyboard: https://github.com/google/physical-web/issues/568. Thanks @hillbrad for pointing out the problem during TPAC.

[beaufortfrancois]

If we go down the Permissions API road (https://lists.w3.org/Archives/Public/public-web-bluetooth/2015Dec/0007.html), it would be as simple as adding a referringDevice key to the Permission object.

permissions.query({ name: 'bluetooth' })
.then(permission => {
  if (permission.state != 'granted') {
    console.log('User has forbidden websites to use bluetooth...');
    return;
  }
  if (permission.referringDevice) {
    // Let's try to connect to the Physical Web object first. 
    return connectDevice(permission.referringDevice);
  }
  ...