Weirdness with WebUSB pairing through Download dialog

[Jaqster]

Windows/Edge Repro -

• micro:bit v2 connected (but not paired yet)
• click Download button
• click Pair Now through dialog
• click Connect to browser

I would expect the Download button to change to the micro:bit icon to show that it's paired, so the next time I click Download it will download via WebUSB. This is not happening. The download button still shows as file download...

[Jaqster]

Trying to upload a video of this...

https://user-images.githubusercontent.com/22108954/174353051-520f56f9-6f2a-459d-b19b-fb4db1a5106a.mp4

[abchatra]

@Jaqster does it atleast paired and one click download works? Is this an icon UI issue?

[Jaqster]

No, it keeps downloading as a file (also throws up this error message). I can refresh the page and then it works.

[pelikhan]

If you add ?webusbdbg=1 to the URL, you'll get detailled logs about what's causing it to fail.

Sent from Outlookhttp://aka.ms/weboutlook

---

From: Jacqueline Russell @.> Sent: Friday, June 17, 2022 1:52 PM To: microsoft/pxt-microbit @.> Cc: Subscribed @.***> Subject: Re: [microsoft/pxt-microbit] Weirdness with WebUSB pairing through Download dialog (Issue #4770)

No, it keeps downloading as a file (also throws up this error message). I can refresh the page and then it works.

— Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fpxt-microbit%2Fissues%2F4770%23issuecomment-1159219454&data=05%7C01%7Cjhalleux%40microsoft.com%7C4a00892645c3429b64bd08da50a34d17%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637910959550432719%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oLDoc9UGrgdKmYOKopv4G8i73Rv9Q9ZkeRdfTdW%2FSKQ%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAA73QKLM4JJFYDMGRGD2MV3VPTQRBANCNFSM5ZDAAXGA&data=05%7C01%7Cjhalleux%40microsoft.com%7C4a00892645c3429b64bd08da50a34d17%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637910959550432719%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EGqVDBUaRjDQwZZXa80iCyuzuVy%2Fyl9jyOBF14pfhCs%3D&reserved=0. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Jaqster]

where do I see the logs?

[pelikhan]

You should see something like this:

What version of edge is this?

[martinwork]

@pelikhan This pairnow.log was captured from Windows 10 Chrome 105.0.5195.127 with URL https://makecode.microbit.org/?dbg=1&webusbdbg=1&webusbfullflash=1#editor and the console set to All levels.

Initially not WebUSB connected, I clicked Download, connected via "pair now" in the Download completed... dialog, then clicked Download.

The micro:bit orange LED flashed as if a transfer was taking place, but the software in micro:bit was left unchanged. The V2.21 MICROBIT drive had the ASSERT.TXT

Assert
File: ../../../source/daplink/drag-n-drop/file_stream.c
Line: 164
Source: Application

https://github.com/microbit-foundation/DAPLink/blob/master/source/daplink/drag-n-drop/file_stream.c#L164

[jwunderl]

I spent about a day last week looking for webusb issues and got a fairly 'stable' way to induce an error like this (/ probably the same error) -- it's not a way a user would likely ever hit but maybe useful for testing / identifying other paths that might get hit. My understanding is that this appeared to be an issue on the micro:bit firmware / daplink side where (if I'm recounting correctly from a meeting a few weeks back) -- the micro:bit side of daplink gets overloaded & starts sending back responses out of order (I believe it was basically sending the response back 1 'late', which would match the error messages below)? The problem 'goes away' when you power cycle the micro:bit (disconnect from computer & battery).

I can't recall for sure but I believe it was @microbit-carlos who was investigating here.

Anyway, repro steps:

1. Go to makecode.microbit.org/#editor (repros in beta as well / no real difference)
2. download button triple dot menu -> connect device -> pair
3. download program to micro:bit
4. reset the page's webusb permissions (right click on lock)
   1. Ignore the prompt to reload the page
5. download button triple dot menu -> connect device -> pair -- browser will show it as successfully paired, we show the 'connected to micro:bit' dialog
   1. first stack trace below occurs here after you dismiss the 'you succeeded' dialog, 'device in use or not found' on get devices req
6. refresh the page (leave micro:bit powered / connected); micro:bit will stall (e.g. if screen was showing image it will stop) - something like bad response 5 -> 131 (bad transfer attempt? or just spurious),
7. Attempting download appears to alternate values (0 -> 5 then 5 -> 0, sometimes 17 -> 0 then 0 -> 17)
8. power cycling micro:bit resolves the issue (no need to re-pair in browser)

stack traces:

before reload (response to second pairing) when it tries to 'reconnect'

Found an ARM Cortex-M4
react_devtools_backend.js:2655 DOMException: Failed to execute 'transferIn' on 'USBDevice': The device was disconnected.
overrideMethod @ react_devtools_backend.js:2655
readSerialLoop @ editor.js:3312
2pxtapp.js:1 webusb: get devices
pxtapp.js:1 Uncaught (in promise) Error: Device in use or not found.
    at o.connectAsync (pxtapp.js:1:422669)
    at async DAPWrapper.reconnectAsync (editor.js:3413:9)
connectAsync @ pxtapp.js:1
pxtapp.js:1 webusb: get devices

after reload -- paired but flashing fails:

packetio: mk wrapper dap wrapper
pxtapp.js:1 webusb: get devices
editor.js:2415 Connecting...
pxtapp.js:1 Error: Bad response for 0 -> 131
    at CMSISDAP.<anonymous> (editor.js:2391:35)
    at step (editor.js:2317:23)
    at Object.next (editor.js:2298:53)
    at fulfilled (editor.js:2289:58)
(anonymous) @ pxtapp.js:1
pxtapp.js:1 webusb: get devices
editor.js:2391 Uncaught (in promise) Error: Bad response for 5 -> 0
    at CMSISDAP.<anonymous> (editor.js:2391:35)
    at step (editor.js:2317:23)
    at Object.next (editor.js:2298:53)
    at fulfilled (editor.js:2289:58)
editor.js:2415 Connecting...
pxtapp.js:1 Error: Bad response for 0 -> 5
    at CMSISDAP.<anonymous> (editor.js:2391:35)
    at step (editor.js:2317:23)
    at Object.next (editor.js:2298:53)
    at fulfilled (editor.js:2289:58)
(anonymous) @ pxtapp.js:1
pxtapp.js:1 webusb: get devices
editor.js:2391 Uncaught (in promise) Error: Bad response for 5 -> 0
    at CMSISDAP.<anonymous> (editor.js:2391:35)
    at step (editor.js:2317:23)
    at Object.next (editor.js:2298:53)
    at fulfilled (editor.js:2289:58)
pxtapp.js:1 webusb: get devices
editor.js:2415 Connecting...
editor.js:2446 Connected
editor.js:1129 6 hardware breakpoints, 4 literal comparators
editor.js:535 Found an ARM Cortex-M4

[martinwork]

@jwunderl I think the problem occurs when not already connected, so the first download goes to file, then you hit "Pair now" in the post download dialog. This has been reported in support tickets, mostly with Chromebooks. I'm testing with Chrome in Windows.

MakeCode seems not to check WebUSB again after the pairing dialogs. There are no new console messages, and the Download icon does not update.

Clicking Download sometimes gives a bad response error. Mostly it seems to work (there is USB activity) except the console has some unexpected messages, as below, but then I see that the program in microbit is not actually changed. A second click on Download is working for me right now, with the Download icon updated.

[jwunderl]

Ah, I see - it looks like I might have conflated the two errors looking at the video (where it shows bad response 0 ->131), but I see the one you're talking about -- it's missing a maybeReconnectAsync() after calling pair: https://github.com/microsoft/pxt/blob/flagNoSimShimsCompile/webapp/src/cmds.ts#L454 where it works vs the modal https://github.com/microsoft/pxt/blob/flagNoSimShimsCompile/webapp/src/dialogs.tsx#L747 -- I'm guessing the video's repro case actually looked more like the one I described (resetting permissions to get it to show in a video) then and was hitting both bugs, but separate causes yes!

Will make https://github.com/microsoft/pxt/pull/9464 fix the bug you're referring to and probably make a separate issue for the 'unlikely for user to hit' repro case I had (will just need to make another test build / test on monday but I'll push the code now). Thanks for pointing that out! (edit: https://github.com/microsoft/pxt/pull/9464/commits/0cc6bd1da41da6a7ddfd994619aac5f168e894ab, need to double check / test it monday~)

[martinwork]

@jwunderl Oh, yes, you're probably right that the bad response happens when I disconnect to try it again. Yesterday, after the first time when I got a bad response. I was being careful to disconnect WebUSB, hit reload, disconnect the micro:bit, and relaunch MakeCode.

[jwunderl]

Fixed the incomplete pairing portion (where it's not working through download dialog) in https://github.com/microsoft/pxt/pull/9464, I'll file a separate issue for the 'disconnect and reconnect in certain ways can get microbit upset side issue