← Back to PRs

#16905: fix: prevent excessive Chrome tab creation on startup

by MisterGuy420 open 2026-02-15 07:15 View on GitHub →
stale size: XS trusted-contributor
## Summary When the browser server creates a new tab via `ensureTabAvailable`, there can be a race condition where the newly opened tab does not immediately have a valid WebSocket URL (wsUrl) for loopback profiles. This can cause the tab selection logic to fail or select the wrong tab, potentially leading to unexpected behavior where additional tabs might be opened. This fix adds: 1. A small delay (100ms) after opening a new tab to allow it to fully initialize 2. Retry logic that waits up to 2 seconds for a valid wsUrl before proceeding with tab selection This helps prevent scenarios where multiple tabs might be opened unnecessarily due to timing issues when the browser first starts. ## Changes - Added 100ms delay after opening a new tab in `ensureTabAvailable` - Added retry loop that waits for valid wsUrl (up to 2 seconds) for loopback profiles - Refactored candidate filtering into a reusable `getCandidates` function ## Testing - All existing browser server-context tests pass (14 tests) - The fix addresses a potential race condition without changing the core logic Fixes openclaw/openclaw#16892 <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR addresses a race condition in `ensureTabAvailable` where newly created Chrome tabs don't immediately have a valid WebSocket URL (`wsUrl`) for loopback profiles. The fix adds a 100ms delay after tab creation and implements retry logic (up to 2 seconds) to wait for tabs to have valid `wsUrl` values before proceeding with tab selection. **Key changes:** - Added 100ms delay after `openTab` to allow tab initialization - Extracted candidate filtering logic into reusable `getCandidates` helper function - Added retry loop that waits up to 2 seconds for loopback profiles to have tabs with valid `wsUrl` - Only applies retry logic when `cdpIsLoopback` is true, candidates are empty, but tabs exist <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with low risk - The changes add defensive retry logic to handle a timing issue without modifying core behavior. The fix is well-scoped to loopback profiles only and uses reasonable timeout values (100ms delay, 2s max wait). All existing tests pass according to the PR description. The only minor concern is the added latency in edge cases, but the delays are small and only apply when truly needed. - No files require special attention <sub>Last reviewed commit: 9e08284</sub> <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs