webhid compute_from api.HIDDevice.open

[nondebug]

WebHID should be compute_from api.HIDDevice.open (record usage when script attempts to open a device) to match how it is recorded in Chromium.

web-features/features/webhid.yml

Line 6 in 35f9d13

compute_from: api.Navigator.hid

https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/webdx_feature_maps.cc;l=125;drc=98446c62425aae85d330b4be247b1336a292dda7

Usage of the navigator.hid attribute is misleading because script may access this to detect browser capabilities without intending to use those capabilities. HIDDevice.open is a much stronger usage signal as it can only be called after permission UI has been shown and the user has granted access.

[nondebug]

Taking a look at other device APIs WebUSB, Web Serial, Web Bluetooth:

---

web-features/features/webusb.yml

Line 6 in 589c8ae

compute_from: api.Navigator.usb

This should be api.USBDevice.open

https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/webdx_feature_maps.cc;l=129;drc=98446c62425aae85d330b4be247b1336a292dda7

---

web-features/features/serial.yml

Line 5 in 589c8ae

compute_from: api.Navigator.serial

This should be api.SerialPort.open

https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/webdx_feature_maps.cc;l=167;drc=98446c62425aae85d330b4be247b1336a292dda7

---

web_bluetooth.yml doesn't have compute_from yet, it should be api.BluetoothRemoteGATTServer.connect to match Chromium's behavior.

https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/webdx_feature_maps.cc;l=163;drc=98446c62425aae85d330b4be247b1336a292dda7

[atopal]

@nondebug Thanks for flagging these. Just to be sure: The compute_from field is used to signal the implementation status between browsers. Usually, this is computed from all the components of an API, but in some cases an API is deemed usable and actually used by developers despite one part being only partially implemented across browsers. In those cases the compute_from field specifies that instead of computing the Baseline status from all components, a specific part of the API should signal the availability across browsers.

An example would be the HTML element <a>. The element has been available in browsers since the first browser, but there is a property called href = 'sms:' that is only available in Firefox. It wouldn't make sense to compute the availability of the element from all the parts in this case, because then we'd have to say that the <a> element is not Baseline, so instead compute_from specifies that the status of just the element itself html.elements.a should be taken to communicate availability. This is a bit of a hack that we eventually want to move away from, but it makes the Baseline status more useful in the meantime.

For the new WebDX use counters Chromium, we are mostly interested in whether developers have decided to adopt a feature, so in cases where there is a difference between adding a capability to a site and users actually making use of the capability, we'd err on the side of measuring the developer decision. That's because we want to have a 1:1 correspondence between WebDX use counters and Web Features.