Files
browse/FIX.md
T
Adam Ladachowski a9f3e63c67 💬 Commit message: Update 2026-02-23 13:06:12, 1 files, 40 lines
📁 Files changed: 1
📝 Lines changed: 40

  • FIX.md
2026-02-23 13:06:12 +01:00

41 lines
1.3 KiB
Markdown

# FIX: Navigation timeout on sites with persistent network activity
## Issue
The `goto` tool times out on sites like LinkedIn that have constant background network activity (tracking, websockets, polling). The tool waits for `networkidle` which never occurs.
**Example:** Navigating to `https://www.linkedin.com/in/aladac/` times out after 30s even though the page is fully rendered and usable.
## Current Behavior
```
page.goto: Timeout 30000ms exceeded.
Call log:
- navigating to "https://www.linkedin.com/in/aladac/", waiting until "networkidle"
```
## Suggested Fix
Add a `waitUntil` parameter to the `goto` tool with options:
- `load` - wait for load event (faster, sufficient for most cases)
- `domcontentloaded` - wait for DOM ready (fastest)
- `networkidle` - current behavior (wait for no network activity for 500ms)
Default should probably be `load` instead of `networkidle`.
### Implementation
In the goto handler, add parameter support:
```typescript
// Instead of:
await page.goto(url, { waitUntil: 'networkidle' });
// Allow:
await page.goto(url, { waitUntil: params.waitUntil ?? 'load' });
```
## Workaround
Currently, if the page loads visually but times out, use `mcp__browse__url` to verify the page is actually loaded - it will return the current URL and title even after goto times out.