Guidance Needed: How complex is it to send user activation data between worker and main thread?

[odej...@chromium.org]

Hello,

I am looking into implementing WebUSB on Dedicated and Shared Workers. The current design is to prevent the requestDevice() method of WebUSB from being accessible within a worker context because requestDevice() produces a chooser that the user can use to select a USB device to connect to. However, I am wondering how difficult it would be to allow a worker to call requestDevice() and send the chooser to appear in the page that started the worker? If it is possible to do this, then for a Shared Worker, many pages from the same origin can be connected to it, what would be the best way to handle showing the chooser to the user in this case?

This is the link to the Intent to Implement on blink-dev@: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/MReOVYgRpKk

Thank you,

Ovidio Henriquez

[Reilly Grant]

I chatted with mustaq@ about this at BlinkOn 9. I'll let him add his thoughts here. I think the short answer is, "this is an interesting space but the user activation work is not yet at a point where we want to consider this."

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

[Mustaq Ahmed]

I agree with Reilly.

The question here touches one of the core things we are changing on through User Activation v2: we are nuking arbitrary forwarding of active tokens because this blocks quite a few bugs on some prominent APIs (in addition to making our codebase overly complicated).  With this new design, popping up a window or a permission dialog from a Worker would be disallowed unless the Worker has its own user-facing page where the user can interact with.  This constraint looks more logical from activation perspective: why should a background process be able to open popups when the user is not even aware of it?

If we have a new use case in WebUSB that needs to bypass this constraint, we will be happy to discuss.  Let's wait until we have one.

[odej...@chromium.org]

So far, there isn't really a use case that needs requestDevice() support in a worker. I think that it is sufficient to use requestDevice() in the page to receive permission to access a USB device, and then using getDevices() in the worker to find the requested USB device.

Thanks for the help!