Can bluetooth objects be used after their originating document is closed? about web-bluetooth

[beaufortfrancois]

@jyasskin Does that include potential service workers and web workers?

[jyasskin]

@beaufortfrancois I haven't thought about workers yet, but I think that, because you can't assign objects directly into a worker, they won't be affected by this sort of difficulty. Cloning and transfering objects results in them having the "right" global, so they probably won't be affected by the old global getting closed.

[marcoscaceres]

Hopefully don't need to write anything as WebIDL should take care of it - though we probably need to check with public-script-coord. When objects are created, they are bound to a "Realm" (the JS context they are created in). Using an object outside of its realm will generally result in a security error (or something like a Wrong Document DOM exception or just a straight up security exception).

[marcoscaceres]

//cc @domenic, who knows more about this...

[domenic]

Using an object outside of its realm will generally result in a security error

I don't think that's quite accurate. In most cases the objects just work (although whatever you do with them will only apply to their originator, not the place you use them).

That seems fine for Bluetooth as well?

[marcoscaceres]

Could be. @jyasskin what are you trying to prevent exactly?

[jyasskin]

Say a web page calls requestDevice() to get permission to access a device, uses the device for a bit without doing anything tricky to pass a reference to another document, and then the user closes the tab. If the user later re-opens a tab to the same origin, should the origin have access to the device?

I believe @adrifelt is going to recommend, based on some user studies, that we persistently pair all devices returned from requestDevice() with the origin (until the user revokes/unpairs them), in which case I think it's straightforward to implement what @domenic suggested. (Right @scheib?) It sounds like this is also the default for the spec, although we might want to make it explicit in a note so implementers don't think they have the freedom to change it.

If we instead wanted to grant only temporary permission to access a device, we'd have a couple choices about when that permission expires:

1. When the original tab is closed: we could specify that the BluetoothDevice object can only be used from its original Document.
2. When the last reference to the BluetoothDevice expires: @scheib thinks this is tricky to implement in Blink.

[scheib]

Yes, from a Blink implementation point of view persistent access and explicit removal of that access is easier to implement.

[adrifelt]

+1 to the idea of persistent access for an origin until revocation, although sadly I do not have any specific studies about Bluetooth in my back pocket

[jyasskin]

Beyond the permission story (where we're going with persistent grants unless someone comes up with an argument otherwise), it's looking like the Chrome implementation is going to have trouble keeping connections open after the originating document/frame/Realm is closed. I'm currently inclined to specify that when the originating document's closed any still-alive objects using that document's global object get disconnected.

@g-ortuno FYI for your implementation patches.

[reillyeon]

Discussed at 2019 TPAC F2F. Persistent permissions have been specified and are being implemented, which resolves the brunt of this issue. Actual transferring ownership of an object between contexts is technically complex and can be avoided with the use of a shared worker or service worker. Closing this in favor of #422.