[Bug]: Sending an openApp or quitApp command to the device causes WebHID to disconnect

[jordaaash]

Impacted Library name

@ledgerhq/live-common

Impacted Library version

33.0.0

Describe the bug

I'm sending these commands over the WebHID transport:

ledger-live/libs/ledger-live-common/src/hw/openApp.ts

Line 3 in 64fd193

await transport.send(0xe0, 0xd8, 0x00, 0x00, Buffer.from(name, "ascii"));

ledger-live/libs/ledger-live-common/src/hw/quitApp.ts

Line 3 in 64fd193

await transport.send(0xb0, 0xa7, 0x00, 0x00);

Testing with the latest Solana and Ethereum apps, with both commands and both apps, the app opens (with a prompt to the user) or quits (without a prompt) successfully, and returns an "Ok" (0x9000) status code.

However, immediately afterward, a disconnect event on the HIDDevice is emitted, causing the transport to be torn down.

Expected behavior

Successfully opening or quitting an app should not cause the transport to disconnect.

Additional context

No response

[jordaaash]

I don't imagine this is actually a bug with the @ledgerhq/live-common library, that's just where these commands come from.

Maybe it could be an issue with the @ledgerhq/hw-transport-webhid or @ledgerhq/hw-transport libraries, but the disconnect event is being emitted on the browser's HIDDevice, so it seems most likely that some response from the device itself is causing the disconnection.

[jordaaash]

Doing some more testing, it looks like the disconnect event is also emitted on the transport just when quitting the running app manually.

[jordaaash]

Currently I'm working around this problem by waiting a short time after opening or quitting an app (4000 milliseconds seems to work) and creating a new WebHIDTransport instance to send the next command. If the new transport is created too quickly, the device won't appear in the list to reconnect immediately.

[jordaaash]

I've observed the same behavior with the WebBLETransport. In this case, the workaround of waiting a few seconds after opening or closing an app doesn't work. Because the bluetooth.requestDevice API requires user interaction, I can't just create a new transport instance to reconnect.

[jordaaash]

Related doc for these commands: https://developers.ledger.com/docs/transport/open-close-info-on-apps/

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label, comment, or consider closing it.

[jordaaash]

Please keep open and fix this, it's an active issue.

[ghost]

@alexandremgo FYI

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label, comment, or consider closing it.

[jordaaash]

This is a bug and is not stale. Please take a look.

[gre]

This is the correct behaviour of our hardware wallets i'm afraid and I'm not aware there is a plan to change anytime soon this behaviour. In Ledger Live we had to workaround the UX around this as well: we're actively waiting a reconnect after doing a openApp / closeApp – this was manageable with node-hid, but on the web i'm not experienced enough to know if it can be done without having to re-ask user's permission (so in a context of a click :s).
basically this comes from the fact an app running on ledger hardware wallet is responsible to create the connectivity stack (USB / BLE / HID / ..) which means each App Open is going to be similar to "plugging a new device" and each App Close is going to be similar to "unplugging that device", same goes with the device's dashboard (the main app screen where you see the apps).
When you obtain a transport, the lifecycle is not the actual usb wire connection but is the lifecycle of the device's app.

So entering an app from the dashboard is essentially a disconnect+connect on the USB stack.

[jordaaash]

Thanks for the response, @gre.

So entering an app from the dashboard is essentially a disconnect+connect on the USB stack.

I haven't found this issue to occur when the user initiates opening an app on the Ledger device (it does occur when exiting one though). It occurs when sending either command to the device over the connected web transport.

For example, I can connect to the device over either the Bluetooth or WebHID transport with the Dashboard open. If I try to send commands for the Solana app, they will fail but not disconnect the transport. If I then open the Solana app on the device, the transport will not disconnect, and subsequent commands to the Solana app will succeed.

Only if I quit the app on the device, or send the commands to quit the current app or open an app, will it cause transport disconnection. This makes these commands not very useful, as the UX of losing the transport connection is pretty bad. Is this expected behavior? What sort of UX do you recommend, for example always asking the user to launch the app themselves before connecting?

[gre]

@jordaaash it's curious that you don't experience a disconnect when entering the app, i'm not familiar with the latest development on the matter so I've asked internally the relevant team who should answer here if they have complementary information 🙏

What sort of UX do you recommend, for example always asking the user to launch the app themselves before connecting?

yes. there are ongoing work toward making the experience more seamless. but for now it's the current status quo i'm afraid.

Thanks

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label, comment, or consider closing it.