buttplugio / buttplug-rs-ffi

FFI from buttplug-rs to Java and other languages
Other
88 stars 22 forks source link

The scanningfinished event is emitted at the wrong time (as far as I can tell). #89

Open phckr opened 2 years ago

phckr commented 2 years ago

Describe the bug The scanningfinished event seems to be emitted at the wrong time. It seems to be emitted before the scanning actually starts.

Expected behavior In particular if I start scanning and then click cancel on the chrome window to stop scanning, then I would expect to get a scanningfinished when that happens.

Example

https://phckr.github.io/testScanning.html

This is a very crude webpage that is based around the documented examples. This is using 1.0.14 as the 1.0.15 doesn't load.

At the bottom of the page, the event log is displayed. The output below was generated from loading the webpage and then clicking on click to start scanning and then clicking cancel on the popup. This latter event did not trigger any log message.

1633627392080: Init start
1633627392112: Waiting for connect
1633627392121: adding listeners
1633627406036: Scanning finished
1633627406036: Scanning started

Additional context Running on Chrome 94 on Linux.

qdot commented 2 years ago

Thanks for pointing this out! This is a tough issue with how WebBluetooth works because we're essentially popping the device select dialog then saying "Ok we're done", which is different than every other system. I'll see if I can delay the scanningfinished event until after the promise for device select resolves.

phckr commented 2 years ago

My workflow is that the user is asked to pair a device, but if the device is already paired, when you press 'pair', you don't get either a scanningfinished or deviceadded message. I guess that this is because the device is already added. Maybe either send another deviceadded event, or send a devicerepaired event instead. You can test this with the same page that I posted above.

I'm trying to keep track of what is going on by reading the event stream.

phckr commented 2 years ago

After more research, I suspected that the root cause is that the JS implemention only uses the buttplug 5.1.4 library. Unfortunately, upgrading this to 5.1.7 doesn't work easily as the introduction of jsonschema somehow pulls in socket2 which doesn't compile on a wasm32 target. There are github issues on socket2 about making this work (at least to build without error): https://github.com/rust-lang/socket2/issues/268

However, I don't actually think that 5.1.7 will fix the problem.

I'm wondering whether to just add a new event for scanningDone that maybe is only sent by the webbluetooth_manager.rs when the user press cancel in the browser popup.

I understand that this is difficult to solve in a platform independent way -- especially since the WASM version can't even use the current buttplug library version.