Worker support

[reillyeon]

Splitting this issue off from #422 because Worker (i.e. Dedicated Worker) support in particular is much easier than Service Worker support because there is always a Document associated with the worker's Javascript context. This is the model used by the worker support in the Web Serial and WebUSB APIs. Usage of those APIs is "charged" to the document which owns the worker. The only architectural blocker for supporting Web Bluetooth in this type of worker is the still-experimental getDevices() method or support for transferring BluetoothDevice instances using postMessage(). The former being how Web Serial and WebUSB handle getting access to a device object from a worker.

[PavelCibulka]

Will devices (for exmaple bluetooth printer, scale and barcode reader) stay connected if:

• page is refreshed (same url)
• page is changed to another one (same domain)
• web browser is completly closed, device restarted and same page reopened

We would like our website manage this devices without constant reconnection or confirmation from employees. Will that be possible with Web Worker? Look at it as classical EXE aplication managing warehouse operations, but running as website.

[ariccio]

@PavelCibulka same questions for me, I am currently spinning up a dedicated react native app to work around these limitations! getDevices got me part of the way there, but it's fundamentally not too workable to ask a customer/user to keep a tab open and babysit it.

[reillyeon]

Using the API from a Worker doesn't solve these problems because dedicated workers are still restarted when the page is navigated or refreshed. The first half of the fix for these issues is the getDevices() API which will allow you to reconnect to the device when the page is reloaded, even if the browser has been completely closed. Maintaining a Bluetooth connection (not re-establishing it) across a navigation will require additional work, probably involving Portals or SharedWorker.

[PavelCibulka]

SharedWorker looks good. So after resolving getDevices() issues, best solution will be XMLHttpRequest for now?

Where will be data about connected ble devices stored? On the device similar to local storage?

If I have multiple tabs opened that use same SharedWorker. Than I use barcode scanner to read EAN. Can SharedWorker identify active tab to send EAN? How this would work?

[ariccio]

You mean some kind of custom data, or just storing the data that it was connected? getDevices works fine for me with BLE.

[PavelCibulka]

You mean some kind of custom data, or just storing the data that it was connected? getDevices works fine for me with BLE.

Just data about connection - like device MAC.

[PavelCibulka]

@reillyeon If I have multiple tabs opened that use same SharedWorker. Than I use barcode scanner to read EAN. Can SharedWorker identify active tab to send EAN? How this would work?

[reillyeon]

The Shared Worker API doesn't include a way to determine the active tab, but tabs can communicate with the shared worker to indicate which tab the user is currently interacting with.