#16905: fix: prevent excessive Chrome tab creation on startup
stale
size: XS
trusted-contributor
Cluster:
Browser Enhancements and Fixes
## 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
#16030: fix(browser): extend single-tab fallback to remote CDP profiles
by lailoo · 2026-02-14
80.4%
#13568: Fix browser (OpenClaw-managed) launch fail by binding remote debugg...
by singlag · 2026-02-10
78.9%
#8614: fix(browser): detect early chromium exit to prevent startup hang
by Wren-OC · 2026-02-04
76.6%
#14944: fix(browser): prefer openclaw profile in headless/noSandbox environ...
by BenediktSchackenberg · 2026-02-12
75.4%
#20688: fix(browser): allow extension reconnect when stale websocket linger...
by HOYALIM · 2026-02-19
75.4%
#19495: fix: handle Chrome process re-parenting on Windows
by andenwick · 2026-02-17
74.9%
#15595: fix(browser): avoid local port conflicts for remote cdp
by TsekaLuk · 2026-02-13
74.6%
#19823: fix(browser): stability improvements for headless Chrome
by Milofax · 2026-02-18
74.2%
#9020: fix(browser): skip port ownership and WS reachability checks for re...
by yepack · 2026-02-04
74.2%
#17760: fix(browser): rewrite 0.0.0.0 and [::] wildcard addresses in CDP We...
by joeharouni · 2026-02-16
74.0%