Update compatibility check #4711
Open
+89
−92
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
WalkthroughThis PR consolidates compatibility checks into a single Changes
Sequence Diagram(s)sequenceDiagram
participant UI as GUI / User
participant PH as PortHandler
participant COMP as checkCompatibility
participant DEV as Device APIs (Serial / Bluetooth / USB)
UI->>PH: initialize / refresh ports
PH->>COMP: checkCompatibility()
COMP-->>PH: {serial:true, bluetooth:true, usb:false}
PH->>DEV: discover devices (types per capability)
DEV-->>PH: device list (bluetooth/serial/usb)
PH-->>UI: updateDeviceList (standardized types: "bluetooth","serial","usb")
note right of PH: Permission requests use deviceType "bluetooth"/"serial"/"usb"
sequenceDiagram
participant Serial as SerialManager
participant COMP as checkCompatibility
Serial->>COMP: isAndroid()
alt Android
Serial->>Serial: init protocols = ["serial", "virtual"] (CapacitorSerial)
else Non-Android
Serial->>Serial: init protocols = ["serial","bluetooth","tcp","virtual"]
end
Serial-->>Caller: protocol list exposed (names: serial, bluetooth, tcp, virtual)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 2 inconclusive)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/js/serial.js (1)
1-32: Missing import for CapacitorSerial causes runtime error on Android.Line 22 references
CapacitorSerialbut it's never imported. This will cause aReferenceErrorwhen the code runs on Android devices, breaking all serial functionality.Add the missing import at the top of the file:
import WebSerial from "./protocols/WebSerial.js"; import WebBluetooth from "./protocols/WebBluetooth.js"; import Websocket from "./protocols/WebSocket.js"; import VirtualSerial from "./protocols/VirtualSerial.js"; +import CapacitorSerial from "./protocols/CapacitorSerial.js"; import { isAndroid } from "./utils/checkCompatibility.js";
🧹 Nitpick comments (1)
src/js/utils/checkCompatibility.js (1)
128-163: Capability checks work but could use clarifying comments.The implementation correctly handles platform-specific capabilities. However, there's a subtle semantic difference:
checkSerialSupport()returns true for Android because native CapacitorSerial is available (even though Web Serial API is not)checkBluetoothSupport()andcheckUsbSupport()return false for Android because native Capacitor implementations aren't ready yetConsider adding brief comments explaining this distinction to help future maintainers understand why serial returns true while bluetooth/USB return false on Android.
Apply this diff to add clarifying comments:
export function checkSerialSupport() { let result = false; if (isAndroid()) { + // Android uses native CapacitorSerial, not Web Serial API result = true; } else if (navigator.serial) { result = true; } else if (isIOS()) { // Not implemented yet } return result; } export function checkBluetoothSupport() { let result = false; if (isAndroid()) { - // Not implemented yet + // Native Capacitor Bluetooth not implemented yet } else if (navigator.bluetooth) { result = true; } else if (isIOS()) { // Not implemented yet } return result; } export function checkUsbSupport() { let result = false; if (isAndroid()) { - // Not implemented yet + // Native Capacitor USB not implemented yet } else if (navigator.usb) { result = true; } else if (isIOS()) { // Not implemented yet } return result; }
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/js/gui.js(1 hunks)src/js/port_handler.js(10 hunks)src/js/serial.js(4 hunks)src/js/utils/checkCompatibility.js(5 hunks)
🧰 Additional context used
🧠 Learnings (9)
📓 Common learnings
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: 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: 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: 4708
File: locales/en/messages.json:7721-7729
Timestamp: 2025-11-20T20:26:40.313Z
Learning: Betaflight Configurator – Firmware Flasher grouping semantics:
- "Verified/Partner": targets with verified schematics and tested prototypes (known working).
- "Unsupported": vendor/community-supplied targets that did not go through the verification program.
- "Legacy": legacy targets kept for existing users.
These labels surface in src/js/tabs/firmware_flasher.js via i18n keys:
firmwareFlasherOptionLabelVerifiedPartner, firmwareFlasherOptionLabelVendorCommunity, firmwareFlasherOptionLabelLegacy. Only English text should be updated directly in locales/en/messages.json; other locales are managed externally.
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: 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: 0
File: :0-0
Timestamp: 2025-05-14T21:51:09.253Z
Learning: On Android Chrome browsers, Web Bluetooth API is supported for BLE devices and Web USB API is supported, but Web Serial API is not supported (except limited Bluetooth serial support added in 2025). The Betaflight Configurator should detect and use available APIs on Android rather than requiring all three.
Learnt from: blckmn
Repo: betaflight/betaflight-configurator PR: 4521
File: src/js/protocols/WebSerial.js:148-151
Timestamp: 2025-06-19T22:13:09.136Z
Learning: In WebSerial.js, there's a timing issue where the cached `this.ports` array doesn't immediately reflect newly permitted devices after `requestPermissionDevice()` completes. The `getDevices()` method needs to refresh the device list from the browser API to return accurate data immediately following a permission request and user acceptance.
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-05-14T21:39:16.388Z
Learning: On Android Chrome browsers, Web Bluetooth API is supported from version 133+ (requires Android 6.0+) and Web USB API is supported from version 136+, but Web Serial API is not supported. The Betaflight Configurator should detect and use available APIs on Android rather than requiring all three.
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4379
File: src/js/protocols/TauriSerial.js:203-259
Timestamp: 2025-10-25T21:16:32.474Z
Learning: In TauriSerial (src/js/protocols/TauriSerial.js), the requestPermissionDevice() method is not needed and not invoked. Tauri automatically discovers serial devices through the constructor's loadDevices() and startDeviceMonitoring() calls, bypassing the browser permission model that WebSerial requires. Devices are auto-detected via a 1-second polling interval without user permission prompts.
📚 Learning: 2025-05-14T21:51:09.253Z
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-05-14T21:51:09.253Z
Learning: On Android Chrome browsers, Web Bluetooth API is supported for BLE devices and Web USB API is supported, but Web Serial API is not supported (except limited Bluetooth serial support added in 2025). The Betaflight Configurator should detect and use available APIs on Android rather than requiring all three.
Applied to files:
src/js/utils/checkCompatibility.jssrc/js/serial.jssrc/js/port_handler.js
📚 Learning: 2025-05-14T21:39:16.388Z
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-05-14T21:39:16.388Z
Learning: On Android Chrome browsers, Web Bluetooth API is supported from version 133+ (requires Android 6.0+) and Web USB API is supported from version 136+, but Web Serial API is not supported. The Betaflight Configurator should detect and use available APIs on Android rather than requiring all three.
Applied to files:
src/js/utils/checkCompatibility.jssrc/js/serial.jssrc/js/port_handler.js
📚 Learning: 2025-10-25T21:16:32.474Z
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4379
File: src/js/protocols/TauriSerial.js:203-259
Timestamp: 2025-10-25T21:16:32.474Z
Learning: In TauriSerial (src/js/protocols/TauriSerial.js), the requestPermissionDevice() method is not needed and not invoked. Tauri automatically discovers serial devices through the constructor's loadDevices() and startDeviceMonitoring() calls, bypassing the browser permission model that WebSerial requires. Devices are auto-detected via a 1-second polling interval without user permission prompts.
Applied to files:
src/js/utils/checkCompatibility.jssrc/js/serial.jssrc/js/port_handler.js
📚 Learning: 2025-11-19T17:55:51.714Z
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4708
File: src/js/tabs/firmware_flasher.js:0-0
Timestamp: 2025-11-19T17:55:51.714Z
Learning: In the betaflight-configurator project, only current Chrome and Edge-based browsers are officially supported, and users are expected to keep their browsers up-to-date for security reasons. This means ES2023 features like Array.prototype.toSorted() and Object.groupBy() can be safely used without polyfills or transpilation.
Applied to files:
src/js/utils/checkCompatibility.js
📚 Learning: 2025-06-19T22:13:09.136Z
Learnt from: blckmn
Repo: betaflight/betaflight-configurator PR: 4521
File: src/js/protocols/WebSerial.js:148-151
Timestamp: 2025-06-19T22:13:09.136Z
Learning: In WebSerial.js, there's a timing issue where the cached `this.ports` array doesn't immediately reflect newly permitted devices after `requestPermissionDevice()` completes. The `getDevices()` method needs to refresh the device list from the browser API to return accurate data immediately following a permission request and user acceptance.
Applied to files:
src/js/utils/checkCompatibility.jssrc/js/serial.jssrc/js/port_handler.js
📚 Learning: 2025-06-09T00:32:21.385Z
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-06-09T00:32:21.385Z
Learning: In the betaflight-configurator codebase, port paths use counter prefixes (e.g., "bluetooth1", "bluetooth2", "serial1") rather than direct protocol identifiers. The protocol selection logic correctly uses `portPath.startsWith("bluetooth")` to detect bluetooth ports regardless of the counter suffix, rather than direct string matching against protocol map keys.
Applied to files:
src/js/serial.jssrc/js/port_handler.js
📚 Learning: 2025-08-22T16:43:20.901Z
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4576
File: src/js/port_usage.js:17-23
Timestamp: 2025-08-22T16:43:20.901Z
Learning: In betaflight-configurator, the serial facade architecture requires accessing metrics like bitrate, bytesReceived, and bytesSent from serial._protocol rather than the top-level serial object. This change maintains compatibility with existing port utilization calculations that have been stable for over 11 years.
Applied to files:
src/js/serial.js
📚 Learning: 2025-06-09T00:33:22.959Z
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-06-09T00:33:22.959Z
Learning: In the betaflight-configurator codebase, port paths use counter suffixes for serial and bluetooth ports (e.g., "serial1", "serial2", "bluetooth1", "bluetooth2") instead of using connectionId, which means simple string matching against protocol map keys won't work for protocol selection.
Applied to files:
src/js/serial.jssrc/js/port_handler.js
🧬 Code graph analysis (2)
src/js/serial.js (1)
src/js/utils/checkCompatibility.js (1)
isAndroid(42-47)
src/js/port_handler.js (4)
src/js/utils/checkCompatibility.js (4)
checkCompatibility(56-126)checkBluetoothSupport(141-151)checkSerialSupport(128-139)checkUsbSupport(153-163)src/components/eventBus.js (2)
EventBus(3-8)EventBus(3-8)src/js/serial.js (2)
serial(224-224)serial(224-224)src/js/protocols/webusbdfu.js (1)
WEBUSBDFU(1279-1279)
🔇 Additional comments (7)
src/js/gui.js (1)
6-6: LGTM!Import path update aligns with the PR's consolidation of compatibility checks into a unified API.
src/js/utils/checkCompatibility.js (2)
7-8: Good defensive programming.Using
globalThis.navigatorprevents potential ReferenceErrors in non-browser environments like tests or SSR contexts.
56-126: Well-structured consolidation of compatibility checks.The new
checkCompatibility()function provides a clear, unified entry point for browser capability verification. The logic correctly requires either a test environment, native platform, or Chromium with at least one working API.src/js/serial.js (2)
81-96: Protocol selection logic correctly updated.The mapping from port paths to protocol names now uses the standardized naming ("serial", "bluetooth") instead of the old "webserial"/"webbluetooth" convention. The logic preserves correct behavior with counter-prefixed paths like "bluetooth1", "bluetooth2".
150-154: Documentation updated to match new naming convention.The JSDoc correctly reflects the renamed protocol types, improving API documentation clarity.
src/js/port_handler.js (2)
1-50: Clean migration to unified compatibility API.The import updates and initialization correctly use the new
checkCompatibility()function and individual capability checks to set feature flags. This aligns well with the PR's goal of consolidating compatibility logic.
53-348: Comprehensive and consistent device type naming standardization.All references to device types have been systematically updated from "webbluetooth"/"webserial" to "bluetooth"/"serial". The changes are thorough and maintain functional equivalence while improving naming consistency across the codebase.
nerdCopter
approved these changes
Nov 21, 2025
Member
nerdCopter
left a comment
nerdCopter
left a comment
There was a problem hiding this comment.
- pre-approving for workflow
- need to locate my OTG for actual testing
|
Contributor
|
Preview URL: https://pr4711.betaflight-app-preview.pages.dev |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/js/serial.js (2)
5-32: Android branch will throw ifCapacitorSerialis not definedOn Android,
isAndroid()will be true in a Capacitor-native build, and the constructor will executenew CapacitorSerial(). BecauseCapacitorSerialis neither imported nor guarded, this will raise aReferenceErroras soon asSerialis instantiated, which matches the PR note that the Android plugin is not yet provided.Consider either importing the implementation once it exists or guarding the branch so current Android builds don’t hard-crash:
- if (isAndroid()) { - this._protocols = [{ name: "serial", instance: new CapacitorSerial() }]; - } else { + if (isAndroid() && typeof CapacitorSerial !== "undefined") { + this._protocols = [{ name: "serial", instance: new CapacitorSerial() }]; + } else { this._protocols = [ { name: "serial", instance: new WebSerial() }, { name: "bluetooth", instance: new WebBluetooth() }, { name: "tcp", instance: new Websocket() }, ]; }If you intend Android builds to remain unusable until the plugin lands, it would still be good to fail with an explicit error/logging message rather than an uninformative
ReferenceError.
151-175: JSDoc-implementation mismatch ingetDevicesandrequestPermissionDevice—optional fallback behavior not implementedThe verification confirms the review's concern: the JSDoc documents
getDevices(protocolType = null)as optional with a fallback to current protocol, but the implementation returns an empty array with a warning whenprotocolTypeisnull.Current findings:
- Registered protocols:
"serial","bluetooth","tcp"(plus"virtual"is referenced but never registered at line 87)- Call sites in
port_handler.jsuse explicit protocol names and always succeed- No legacy names (
webserial,webbluetooth,websocket) are currently used in the codebase, so there is no breaking change from name migration- However, the JSDoc-implementation contract is violated: the documented optional parameter and fallback behavior are not provided
The suggested fix in the review (supporting legacy names and implementing the documented fallback) is reasonable for API consistency, though not required by current call sites.
Additionally, there's an orphaned check for
"virtual"protocol at line 87 that references a protocol never registered in_protocols.
🧹 Nitpick comments (1)
src/js/serial.js (1)
81-96: Protocol selection logic aligns with naming, but undefined protocol on Android should be confirmedThe updated
selectProtocolcorrectly:
- Treats functions /
"virtual"as virtual ports.- Routes
"manual"and tcp/ws/wss URLs to the protocol named"tcp".- Routes paths starting with
"bluetooth"to the"bluetooth"protocol, which matches the existing"bluetooth1","bluetooth2"prefix convention. Based on learnings.On Android,
_protocolsonly contains"serial"(CapacitorSerial) and"virtual", so any"tcp"or"bluetooth"lookup will returnundefined.connect()then throws when calling.connectonundefined, which is caught and surfaces only as a generic error.If port paths like
"bluetooth1"or tcp/ws URLs truly cannot be produced on the Android/Capacitor build, this is fine; otherwise, consider either:
- Normalizing these paths earlier so they never reach
selectProtocolon Android, or- Adding an explicit check and clearer error when a requested protocol type is not available on the current platform.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/js/serial.js(4 hunks)
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-06-09T00:32:21.385Z
Learning: In the betaflight-configurator codebase, port paths use counter prefixes (e.g., "bluetooth1", "bluetooth2", "serial1") rather than direct protocol identifiers. The protocol selection logic correctly uses `portPath.startsWith("bluetooth")` to detect bluetooth ports regardless of the counter suffix, rather than direct string matching against protocol map keys.
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: blckmn
Repo: betaflight/betaflight-configurator PR: 4521
File: src/js/protocols/WebSerial.js:148-151
Timestamp: 2025-06-19T22:13:09.136Z
Learning: In WebSerial.js, there's a timing issue where the cached `this.ports` array doesn't immediately reflect newly permitted devices after `requestPermissionDevice()` completes. The `getDevices()` method needs to refresh the device list from the browser API to return accurate data immediately following a permission request and user acceptance.
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-05-14T21:51:09.253Z
Learning: On Android Chrome browsers, Web Bluetooth API is supported for BLE devices and Web USB API is supported, but Web Serial API is not supported (except limited Bluetooth serial support added in 2025). The Betaflight Configurator should detect and use available APIs on Android rather than requiring all three.
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4379
File: src/js/protocols/TauriSerial.js:203-259
Timestamp: 2025-10-25T21:16:32.474Z
Learning: In TauriSerial (src/js/protocols/TauriSerial.js), the requestPermissionDevice() method is not needed and not invoked. Tauri automatically discovers serial devices through the constructor's loadDevices() and startDeviceMonitoring() calls, bypassing the browser permission model that WebSerial requires. Devices are auto-detected via a 1-second polling interval without user permission prompts.
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-05-14T21:39:16.388Z
Learning: On Android Chrome browsers, Web Bluetooth API is supported from version 133+ (requires Android 6.0+) and Web USB API is supported from version 136+, but Web Serial API is not supported. The Betaflight Configurator should detect and use available APIs on Android rather than requiring all three.
📚 Learning: 2025-10-25T21:16:32.474Z
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4379
File: src/js/protocols/TauriSerial.js:203-259
Timestamp: 2025-10-25T21:16:32.474Z
Learning: In TauriSerial (src/js/protocols/TauriSerial.js), the requestPermissionDevice() method is not needed and not invoked. Tauri automatically discovers serial devices through the constructor's loadDevices() and startDeviceMonitoring() calls, bypassing the browser permission model that WebSerial requires. Devices are auto-detected via a 1-second polling interval without user permission prompts.
Applied to files:
src/js/serial.js
📚 Learning: 2025-06-19T22:13:09.136Z
Learnt from: blckmn
Repo: betaflight/betaflight-configurator PR: 4521
File: src/js/protocols/WebSerial.js:148-151
Timestamp: 2025-06-19T22:13:09.136Z
Learning: In WebSerial.js, there's a timing issue where the cached `this.ports` array doesn't immediately reflect newly permitted devices after `requestPermissionDevice()` completes. The `getDevices()` method needs to refresh the device list from the browser API to return accurate data immediately following a permission request and user acceptance.
Applied to files:
src/js/serial.js
📚 Learning: 2025-06-09T00:32:21.385Z
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-06-09T00:32:21.385Z
Learning: In the betaflight-configurator codebase, port paths use counter prefixes (e.g., "bluetooth1", "bluetooth2", "serial1") rather than direct protocol identifiers. The protocol selection logic correctly uses `portPath.startsWith("bluetooth")` to detect bluetooth ports regardless of the counter suffix, rather than direct string matching against protocol map keys.
Applied to files:
src/js/serial.js
📚 Learning: 2025-05-14T21:51:09.253Z
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-05-14T21:51:09.253Z
Learning: On Android Chrome browsers, Web Bluetooth API is supported for BLE devices and Web USB API is supported, but Web Serial API is not supported (except limited Bluetooth serial support added in 2025). The Betaflight Configurator should detect and use available APIs on Android rather than requiring all three.
Applied to files:
src/js/serial.js
📚 Learning: 2025-08-22T16:43:20.901Z
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4576
File: src/js/port_usage.js:17-23
Timestamp: 2025-08-22T16:43:20.901Z
Learning: In betaflight-configurator, the serial facade architecture requires accessing metrics like bitrate, bytesReceived, and bytesSent from serial._protocol rather than the top-level serial object. This change maintains compatibility with existing port utilization calculations that have been stable for over 11 years.
Applied to files:
src/js/serial.js
📚 Learning: 2025-05-14T21:39:16.388Z
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-05-14T21:39:16.388Z
Learning: On Android Chrome browsers, Web Bluetooth API is supported from version 133+ (requires Android 6.0+) and Web USB API is supported from version 136+, but Web Serial API is not supported. The Betaflight Configurator should detect and use available APIs on Android rather than requiring all three.
Applied to files:
src/js/serial.js
📚 Learning: 2025-06-09T00:33:22.959Z
Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-06-09T00:33:22.959Z
Learning: In the betaflight-configurator codebase, port paths use counter suffixes for serial and bluetooth ports (e.g., "serial1", "serial2", "bluetooth1", "bluetooth2") instead of using connectionId, which means simple string matching against protocol map keys won't work for protocol selection.
Applied to files:
src/js/serial.js
🧬 Code graph analysis (1)
src/js/serial.js (1)
src/js/utils/checkCompatibility.js (1)
isAndroid(42-47)
blckmn
approved these changes
Nov 22, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Preparing for other protocols
Summary by CodeRabbit
New Features
Improvements
✏️ Tip: You can customize this high-level summary in your review settings.