Skip to content
This repository has been archived by the owner on Jun 27, 2022. It is now read-only.

Problem with WebUSB + Chrome 91.X #607

Closed
humanumbrella opened this issue May 27, 2021 · 33 comments
Closed

Problem with WebUSB + Chrome 91.X #607

humanumbrella opened this issue May 27, 2021 · 33 comments

Comments

@humanumbrella
Copy link
Contributor

Mostly an FYi as I am still searching for answers.

After updating to Chrome 91, when attempting to connect to either Ledger device (X or S), I am seeing the opportunity to pair the device as normal, what looks like a successful pairing, but then when I try to do any operation, I am getting The device was disconnected.

This is for existing applications that work fine on Chrome 90.X.

@humanumbrella
Copy link
Contributor Author

Device shows up and appears to be behaving properly in chrome://usb-internals/

Ultimately, I am trying to use const transport = await TransportWebUsb.create() - and now this does not work in newest Chromium version or any browser that uses it. It does not seem to matter if I am connecting via a saved (previously paired) device or have reset that and connecting fresh. I get the same outcome. Pasting some output from chrome://device-log/

USBUser[13:50:56] USB device added: vendor=11415 "Ledger", product=4117 "Nano S", serial="0001", guid=02b2cba5-69d7-4984-814f-40f524495323

USBEvent[13:50:56] Failed to open device: No such device (it may have been disconnected)

USBUser[13:50:56] USB device removed: guid=7d99e9c9-ff3b-47b4-9281-5a0d0dd14294

USBEvent[13:50:56] Failed to claim interface: Other error

USBUser[13:49:21] USB device added: vendor=11415 "Ledger", product=4117 "Nano S", serial="0001", guid=7d99e9c9-ff3b-47b4-9281-5a0d0dd14294

USBEvent[13:49:20] Failed to open device: No such device (it may have been disconnected)

USBUser[13:49:20] USB device removed: guid=197e5832-548f-43c0-bc7e-b9294581db7b

USBEvent[13:49:20] Failed to claim interface: Other error

Any clients that have Chrome auto-update turned on are now affected and unable to use their devices. Please advise.

cc @meriadec as you fixed hw-transport-webusb last time.

@humanumbrella
Copy link
Contributor Author

I didn't mention but I already tried to flip the bit in chrome://flags to NEW USB Backend to Disabled

It still does not work, the behavior is:

First try - Unable to claim interface.
Second try - The device was disconnected.

@humanumbrella
Copy link
Contributor Author

Bump - this is a major issue, please advise. I am continuing to debug further.

Is anyone from Ledger able to assist?

@MattG561
Copy link

Can confirm that Ledger's WebUSB transport is broken in Chrome version 91 and up. Works with Brave (based on chromium v90) in the meantime.

Would be really nice if Ledger could implement a fix for their transport. It has been a bit unreliable as of late, especially on Windows machines & newer version of Chrome.

@MattG561
Copy link

MattG561 commented May 28, 2021

@humanumbrella Are you using the latest version of the WebUSB transport (5.51.1)?

@alexshchur
Copy link

alexshchur commented May 28, 2021

Confirming this issue. Transport.open returns a rejected promise with the message "index.js:1 Error creating transport: DOMException: The device was disconnected".

At the moment the only way to make Ledger work on MacOS on chrome 91 is to use WebHID transport it seems

@humanumbrella
Copy link
Contributor Author

@humanumbrella Are you using the latest version of the WebUSB transport (5.51.1)?

I have multiple setups, some with latest everything (transport/firmware/btc app) and some not on latest.

Even with toggling New USB Backend I cannot get anything to work as is in Chrome v91.x

@MattG561
Copy link

@humanumbrella Are you using the latest version of the WebUSB transport (5.51.1)?

I have multiple setups, some with latest everything (transport/firmware/btc app) and some not on latest.

Even with toggling New USB Backend I cannot get anything to work as is in Chrome v91.x

Okay, same here. Hoping Ledger comments on this asap.

@humanumbrella
Copy link
Contributor Author

I wrote here and in their Ledger Devs slack #support channel yesterday. It's getting late on a Friday night in France so I am assuming it will be quiet, but hoping to be surprised!

@Velenir
Copy link

Velenir commented May 29, 2021

I made a sandbox to test connection with different transports:

On Linux (Ubuntu 20.04):

  • Firefox: only U2F is supported and works
  • Chrome 91: Bluetooth not supported, other transports supported but U2F breaks with Failed to sign with Ledger device: U2F DEVICE_INELIGIBLE

On Windows:

  • Firefox: only U2F is supported and works
  • Chrome 91: every transport is supported and works, but WebUSB sometimes doesn't connect at first

Can someone try on MacOS please

@MattG561
Copy link

I made a sandbox to test connection with different transports:

On Linux (Ubuntu 20.04):

  • Firefox: only U2F is supported and works
  • Chrome 91: Bluetooth not supported, other transports supported but U2F breaks with Failed to sign with Ledger device: U2F DEVICE_INELIGIBLE

On Windows:

  • Firefox: only U2F is supported and works
  • Chrome 91: every transport is supported and works, but WebUSB sometimes doesn't connect at first

Can someone try on MacOS please

@Velenir How did you manage to get the WebUSB transport working on Chrome 91? Ledger's docs say that U2F is deprecated on all platforms/transports and should be avoided.

@Velenir
Copy link

Velenir commented May 30, 2021

@Velenir How did you manage to get the WebUSB transport working on Chrome 91? Ledger's docs say that U2F is deprecated on all platforms/transports and should be avoided.

@MattG561
I didn't do anything particular, didn't flip any browser flags or anything like that. It just worked for me on Windows, Chrome 91.0.4472.77 (Official Build) (64-bit). You can see the code in the sandbox above

https://user-images.githubusercontent.com/5121491/120099625-39b50180-c145-11eb-9314-c37137daec19.mp4
(Don't have a Ledger with bluetooth though)

While U2F is deprecated it's the only transport that is supported on Firefox, so have to use it there.

@skoold2003
Copy link

I've found that it's not working on Firefox either. It may be unrelated but when I try to connect on V.88.0.1 I get "Uncaught (in promise) Error: navigator.usb is undefined"

@bkbooth
Copy link

bkbooth commented May 31, 2021

Looks like Brave just updated to Chromium v91, Ledger WebUsb no longer working there either.

@skoold2003 WebUsb never worked in Firefox, it's not supported. If you're talking about U2F, it's still working for me in FF today.

@Phunk87
Copy link

Phunk87 commented May 31, 2021

We've tried via WebHID and it works. @humanumbrella

const transport = await TransportWebHID.create()

@humanumbrella
Copy link
Contributor Author

Any help from Ledger on this one, @gre ?

Obviously based on commentary here there is a major problem in the latest Chrome update regarding WebUSB connection. My team can move to add in support for WebHID, which appears to be working, but would really like to know why WebUSB is not working, especially if it's something trivial. Also, the ledgerjs README shows WebHID as experimental, so I am a little hesitant to promote that at the moment.

Screen Shot 2021-06-01 at 12 56 30 AM

Please advise.

@gre
Copy link
Contributor

gre commented Jun 1, 2021

@humanumbrella I think we have to update this README that do not reflect the technical reality anymore. It's clear that Chrome want to sunset our usage of U2F for bidirectional communication as it was documented in https://github.com/LedgerHQ/ledgerjs/blob/master/docs/migrate_webusb.md

Right now, both WebUSB and WebHID are in Drafts stages ( https://wicg.github.io/webusb/ and https://wicg.github.io/webhid/ ). WebHID is more and more the direction we would recommend but there is still a ❓ regarding more browser to support it and which technology will be favorized in the future (as soon as these specs leave the Draft phase).

@humanumbrella
Copy link
Contributor Author

@gre - thank you very much for this information! I will proceed with getting our team to include WebHID support.

Can you confirm whether anyone at Ledger can look at this WebUSB problem? I genuinely believe it's something trivial about a timeout or command rate limiting or something. The reason that I believe this is because the browser is fully able to both see and pair with the device (which seems to be the hard part) but then on an attempt at any communication with the device, an error is thrown.

@MattG561
Copy link

MattG561 commented Jun 1, 2021

@gre - thank you very much for this information! I will proceed with getting our team to include WebHID support.

Can you confirm whether anyone at Ledger can look at this WebUSB problem? I genuinely believe it's something trivial about a timeout or command rate limiting or something. The reason that I believe this is because the browser is fully able to both see and pair with the device (which seems to be the hard part) but then on an attempt at any communication with the device, an error is thrown.

It would really be unfortunate to allocate resources to fixing a potentially trivial problem. Would love it if we can get WebUSB working again.

@humanumbrella
Copy link
Contributor Author

Sorry for the post/delete spam, I didn't want to send down a wild goose chase but ultimately that's what I'm on.

I am not sure, but I think that this recently added webusb related 'fix' could be the source of the problem --> https://chromium-review.googlesource.com/c/chromium/src/+/2829452

usb: Fix crash on Windows when there are no interfaces

This change fixes an invalid pointer read when there are no interfaces
on a USB device, as this leaves the |info| field of the UsbInterfaceInfo
struct uninitialized. To solve this the most commonly used data read
through this pointer is copied directly into the UsbInterfaceInfo struct
and fake data is created when there are no interfaces but the structure
is still needed for internal bookkeeping purposes.

We could really use some help from a Ledger dev here.

@humanumbrella
Copy link
Contributor Author

Can confirm that Ledger Nano S / Nano X work fine in Windows Chrome 91.X - so maybe this^ crash fix for Windows breaks it everywhere else? Not sure...

@MattG561
Copy link

MattG561 commented Jun 2, 2021

Can confirm that Ledger Nano S / Nano X work fine in Windows Chrome 91.X - so maybe this^ crash fix for Windows breaks it everywhere else? Not sure...

I'm very surprised that such a large issue hasn't been addressed yet. It's been almost a week without any sign that they're actively working on this.

@gre
Copy link
Contributor

gre commented Jun 3, 2021

Please help us confirm this fixes works https://github.com/LedgerHQ/ledgerjs/releases/tag/v5.53.0
It was validated by us internally but deserve most testing from all various usage of the transport.

I've also deployed a new version of https://ledger-repl.vercel.app/ that ease the test on this and that we can all test to confirm it's working. (project is https://github.com/LedgerHQ/ledger-repl , access to previous version that had the bug https://ledger-repl-a2770cdok.now.sh/ )

@MattG561
Copy link

MattG561 commented Jun 3, 2021

Please help us confirm this fixes works https://github.com/LedgerHQ/ledgerjs/releases/tag/v5.53.0
It was validated by us internally but deserve most testing from all various usage of the transport.

I've also deployed a new version of https://ledger-repl.vercel.app/ that ease the test on this and that we can all test to confirm it's working. (project is https://github.com/LedgerHQ/ledger-repl , access to previous version that had the bug https://ledger-repl-a2770cdok.now.sh/ )

@humanumbrella @gre I'm noticing an error with WebUSB when attempting to disconnect the device.

const onDisconnect = e => {
      if (device === e.device) {
        // $FlowFixMe
        navigator.usb.removeEventListener("disconnect", onDisconnect);
        transport._emitDisconnect(new DisconnectedDevice());
      }
    }; // $FlowFixMe

Will throw the following error:
DOMException: An operation that changes interface state is in progress.

I've never encountered this with WebUSB when it was working (pre Chrome 91.X).

@gre
Copy link
Contributor

gre commented Jun 3, 2021

@MattG561 @kwunyeung @refi93 @hritique @JacobR & everyone:

Apologies for a too quick attempt to fix the problem that ends up being incomplete to fully resolve this connectivity issue.

I'm issuing right now a 5.53.1 that will revert the incomplete fix attempt back to 5.52.0. We are searching for a better solution now.

While the fixes works most of the time, there are cases that we later identified with more extensive QA that makes it actually not "openable" again. As @MattG561 also quickly reported. ok maybe it's another issue you are having, we will need more investigation to understand this one too.

Thanks for your reactivity and again sorry for the too fast release. Next time we will do a beta bump version instead of using "latest" NPM channel.


I'm done on my side for today but we will continue the investigation tomorrow.

One quick thought I had tonight is we may attempt something like (pseudo code)

try {
  ...await usual open logic...
} catch (e) {
  if ( ... match the exact error case of the problem ... ) {
    await gracefullyResetDevice(device);
    ... do a new attempt to open logic ... 
  }
}

i'm not sure if this idea is viable but worth a try. But more expertise on the topic will be done to maybe rebuild from ground up this transport.

@gre
Copy link
Contributor

gre commented Jun 3, 2021

Could you also share on which OS are we all having issues? We have identified in our side that it's possibly mainly on Mac OS.

refi93 added a commit to vacuumlabs/adalite that referenced this issue Jun 3, 2021
refi93 added a commit to vacuumlabs/adalite that referenced this issue Jun 3, 2021
@MattG561
Copy link

MattG561 commented Jun 3, 2021

@gre The issue mentioned above was solved on my end and was not due to the update (as far as I know). I am still bumping into the same problem you've described above with the device not being openable again.

Environment info:
macOS Big Sur (version 11.3 20E232)
Chrome version 91.0.4472.77
Ledger Firmware 2.0.0

@0xslipk
Copy link

0xslipk commented Jun 4, 2021

@gre I tried with version @ledgerhq/hw-transport-webusb@5.53.0, but got a different this time: Unknown Status Code: 28161

Environment info:
macOS Catalina (version 10.15.7 19H15)
Chrome version 91.0.4472.77 (Official Build) (x86_64)
Ledger Firmware 2.0.0

@pochocosta
Copy link

I'm having the same issue in https://explore-fetchhub.fetch.ai/ and https://cosmoscan.io both in Cosmos ecosystem. But I confirm that I could connect with Metamask (ETH), Zillet.io (Zilliqa), Solflare (Solana) and other apps correctly. The problem for me it's only with apps based in Cosmos.

message: "navigator.usb is undefined"​
name: "TransportOpenUserCancelled"

Environment info:
macOS Big Sur 11.4 (20F71)
Brave Version 1.25.68 Chromium: 91.0.4472.77 (Build oficial) (x86_64)
Firefox version 89.0 (64-bit)
Cosmos app v2.18.0
Ledger Live v2.26.1

@humanumbrella
Copy link
Contributor Author

humanumbrella commented Jun 4, 2021

@gre 0.53.0 fixed it for us and I believe for a lot of folks based on the mentions of this issue in merges on other projects. I am not sure the details of the problems you all saw that caused revert in 0.53.1, but we will be sticking with 0.53.0 until Chromium releases the patch reverting the change they made. I had filed a bug report there, which it looks like some other Ledger family members (Steph) have found and commented on. Definitely send them a device! Hehe.

@jarcodallo You are connecting with the app open on the device, yes? I can confirm that BTC app 1.6.1 with @ledgerhq/hw-transport-webusb@5.53.0 works in Chromium 91.0.4472.77 on MacOS Big Sur. Maybe there is something different with Catalina and you have to wait for the Chromium update (bug report linked above)

@pochocosta WebUSB does not work in Firefox. It works for us in Chromium 91.X with @ledgerhq/hw-transport-webusb@5.53.0

The Caravan Test Suite is an easy way to see if it's working with the Bitcoin app.

  • Select Ledger
  • Then BEGIN TEST SUITE
  • Then START TEST

There is no need to restore using the test suite, though you can if you want to. The point is that the test will fail but the device will respond.

@dotproto
Copy link

dotproto commented Jun 5, 2021

Is this issue related to https://crbug.com/1215767?

@meriadec
Copy link
Member

meriadec commented Jun 7, 2021

FYI there is an active issue on the Chromium project (base project of Chrome) where Ledger took part in the discussion https://bugs.chromium.org/p/chromium/issues/detail?id=1215767

The bug has been identified in Chrome 91 and revert has been successfully tested
For now, it's available on Chrome 93 (Canary, a.k.a developer preview)

official builds can be found here: https://www.google.com/chrome/canary/

it's not clear if the fix is meant to be ported in Chrome 91 / 92, despite some comments on the ticket mention that they are on the fix target
for pessimistic option, you can find the Chrome release schedule here: https://www.chromestatus.com/features/schedule
which say Chrome 93 will be released on Aug 31

@humanumbrella
Copy link
Contributor Author

Afaict this is no longer an issue. The Chromium issue is closed. Cheers

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests