Connections issues that leaves the UI in a broken state.

[hydra]

Describe the bug

I just built a BF target from master and used the online app.betaflight.com configurator to flash it, no problems, but when I connect it says I need a newer version of firmware, but there is no newer version of firmware, since I just built it from master...

It then leaves the UI in a broken state which cannot be recovered.

Discord chat link: https://discord.com/channels/868013470023548938/1019022739044057128/1450886747457323048

To Reproduce

1. Flash firmware from firmware repo, using master which was at git rev: f490d75af25b2892af57b229a4ae82954267f3bf
2. Press Connect
3. Observe error message about 'newer version'.
4. Press OK.
5. Observe CLI doesn't connect. Observe MSP version is reported as 0.0.0 in the log.
6. Press Disconnect.
7. Observe UI is now in a broken state - Only CLI on left hand side, no port selection control, etc.

Expected behavior

A working configurator. No error messages. A cli that works even if the firmware is too old. Useful error messages when there are communication issues.

App version

2025.12.0-RC4 (d0a3ff8)

Flight controller configuration

There seems to be multiple issues:
1) a communication error resuing in an invalid MSP version.
2) incorrect handling of invalid MSP version and/or failed communications.
3) incorrect error messages - perhaps 'communication error' with some information to help diagnose the issue.

Add any other context about the problem that you think might be relevant here

Initial error was with Google Chome: Version 143.0.7499.109 (Official Build) (64-bit) Windows 11 24Q2.
Upgraded to Version 143.0.7499.147 (Official Build) (64-bit) and things were better.

Videos:

1. first occurence of the issue, with Google Chome: Version 143.0.7499.109
   https://github.com/user-attachments/assets/07bd268d-a31a-4a87-9c95-690321c413e7

2. second issue with Google Chome: Version 143.0.7499.147
   https://github.com/user-attachments/assets/0b42729a-a816-4e53-8df1-9721e9f7e414

[hydra]

Here's the 'first-flash' experience, as if the user had never ran BF or used the FC before, with developer console enabled.

https://youtu.be/zeVNgjSu0lw

[nerdCopter]

~ @ 3:52 did the FC reboot? i almost always physically unplug/replug, but agree there should be a software solution as well.

[haslinghuis]

@coderabbitai - should be resolved in #4746

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch details about issue #4745
gh issue view 4745 --repo betaflight/betaflight-configurator --json title,body,labels,state

# Fetch details about PR #4746
gh pr view 4746 --repo betaflight/betaflight-configurator --json title,body,labels,state,files

# Get the diff from PR #4746 to understand the changes
gh pr diff 4746 --repo betaflight/betaflight-configurator

Length of output: 7371

---

@haslinghuis, thanks for the update! I've reviewed PR #4746 and it looks like a comprehensive fix for the first-flash experience issues shown in the video:

Key fixes that address the issue:

1. USB device removal handling - The PR adds proper removedDevice handling in port_handler.js and fixes a critical bug in webusbdfu.js where the disconnect event was incorrectly calling handleNewDevice instead of handleRemovedDevice. This should prevent the UI from getting stuck with invalid port references.

2. DFU port cleanup - After flashing, the port will now properly show "no selection" instead of staying on the now-invalid DFU port, which was likely contributing to the connection failures.

3. Removed overly strict API version check - The API_VERSION_MAX_SUPPORTED check in serial_backend.js has been removed, eliminating false-positive version mismatch warnings that were blocking connections.

These changes directly address the broken UI state and connection issues demonstrated in hydra's video. The fix should provide a much smoother first-flash experience! 🎉

---

🧠 Learnings used

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4510
File: src/js/msp.js:384-391
Timestamp: 2025-09-19T20:42:20.332Z
Learning: Complex MSP duplicate handling fixes in Betaflight Configurator can cause infinite loading messages when changing tabs due to disruption of the callback resolution mechanism. Simple code-only duplicate detection (using this.callbacks.some((instance) => instance.code === code)) is the safer approach that preserves tab switching functionality.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4510
File: src/js/msp.js:384-391
Timestamp: 2025-09-19T20:41:44.286Z
Learning: When fixing MSP duplicate handling in Betaflight Configurator, avoid complex changes to callback resolution mechanisms as they can break tab switching functionality. Simple duplicate detection based on code and payload size is safer than complex requestKey-based approaches.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-12-09T15:06:12.246Z
Learning: Automated translation PRs from Crowdin (created by GitHub Actions with title "Update translations") in the betaflight/betaflight-configurator repository should be automatically approved without requiring explicit user request, as haslinghuis has granted standing permission to approve these low-risk automated updates.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4532
File: src/js/VirtualFC.js:234-234
Timestamp: 2025-06-27T22:06:49.210Z
Learning: In the betaflight-configurator codebase, the VirtualFC.js AUX_CONFIG array must stay synchronized with the betaflight firmware's msp_box.c definitions to ensure proper auxiliary mode functionality. Changes to mode names should follow the firmware source code even if it potentially breaks backward compatibility with saved presets.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4532
File: src/js/VirtualFC.js:234-234
Timestamp: 2025-06-27T22:06:49.210Z
Learning: In the betaflight-configurator codebase, the VirtualFC.js AUX_CONFIG array must stay synchronized with the betaflight firmware's msp_box.c definitions to ensure proper auxiliary mode functionality. Changes to mode names should follow the firmware source code even if it potentially breaks backward compatibility with saved presets.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4597
File: src/js/utils/common.js:95-127
Timestamp: 2025-09-09T20:02:33.475Z
Learning: In the Betaflight Configurator codebase, the Chromium v140 compatibility issue with sortSelect was resolved by rewriting the implementation to use native DOM APIs (Array.from, select.options, select.remove, select.add) instead of jQuery DOM manipulation methods (this.children, this.empty().append). The fix still performs DOM operations but avoids the specific jQuery methods that were causing issues in Chromium v140.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4579
File: src/js/data_storage.js:9-9
Timestamp: 2025-08-27T22:07:26.353Z
Learning: In the betaflight-configurator CalVer refactoring, the generateVirtualApiVersions function in src/js/utils/common.js works correctly despite the apparent mathematical issue with bounds logic where compareVersions.minor() returns different ranges for API_VERSION_MAX_SUPPORTED (25.12.0) vs API_VERSION_ACCEPTED (1.44.0).

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-12-14T20:22:03.580Z
Learning: In betaflight-configurator's msp.js, the bluetooth CRC bypass check at line 266 uses serial.protocol === "bluetooth". When protocol names are unified to "ble", this check must be updated to serial.protocol === "ble".