cremote/TIMEOUT_UPDATE_SUMMARY.md

Default Timeout Update Summary

Overview

Updated all default timeout values from 5 seconds to 30 seconds across the cremote codebase to provide more reasonable defaults for browser automation operations.

Files Modified

1. daemon/daemon.go

Updated all default timeout values:

• General operations: 5s → 30s (86 instances)
• Selection timeouts: 5s → 30s (form operations, element selection)
• Action timeouts: 5s → 30s (clicks, form submissions, file uploads)
• Comments: Updated all "default to 5 seconds" → "default to 30 seconds"

Exceptions kept at higher values:

• Bulk operations: 30s (unchanged)
• Axe-core testing: 30s (unchanged)
• OCR processing: 30s (unchanged)
• Library injection: 10s (unchanged)
• Keyboard testing: 15s (unchanged)
• Various accessibility tests: 10-15s (unchanged)

2. main.go

Updated CLI flag defaults:

• openTabTimeout: 5s → 30s
• loadURLTimeout: 5s → 30s

3. mcp/main.go

Updated MCP server defaults:

• Tool schema defaults: Updated all "default": 5 → "default": 30 in InputSchema definitions
• getIntParam calls: Updated all getIntParam(params, "timeout", 5) → getIntParam(params, "timeout", 30)
• Description strings: Updated all "(default: 5)" → "(default: 30)"

Total changes in mcp/main.go:

• ~40+ tool schema default values
• ~35+ getIntParam default values
• ~40+ description strings

Rationale

Why 30 seconds?

1. Browser automation is inherently slow: Modern web pages with heavy JavaScript can take 10-20 seconds to fully load
2. Network variability: Users may have slower connections or be testing remote sites
3. Reduces timeout errors: 5 seconds was too aggressive and caused frequent timeout failures
4. Industry standard: Most browser automation tools (Selenium, Playwright, Puppeteer) use 30s as default
5. Better user experience: Users can always override with shorter timeouts if needed, but starting with a reasonable default prevents frustration

Operations that benefit most:

• Page navigation and loading
• Element selection (waiting for elements to appear)
• Form interactions (especially with validation)
• File uploads
• JavaScript execution
• Screenshot capture

Testing

✅ Code compiles successfully
✅ All timeout values updated consistently
✅ Comments and documentation updated
✅ No breaking changes (users can still override timeouts)

Migration Notes

• No breaking changes: This only affects default values
• Backward compatible: Users who explicitly set timeout parameters will see no change
• Performance impact: Operations may take longer to timeout, but this is intentional
• User override: All timeout parameters can still be explicitly set to any value

Examples

Before:

timeout := 5  // Default: 5 seconds

After:

timeout := 30  // Default: 30 seconds

MCP Tool Before:

"timeout": map[string]any{
    "type":        "integer",
    "description": "Timeout in seconds (default: 5)",
    "default":     5,
}

MCP Tool After:

"timeout": map[string]any{
    "type":        "integer",
    "description": "Timeout in seconds (default: 30)",
    "default":     30,
}

Related Documentation

• See mcp/PERFORMANCE_BEST_PRACTICES.md for timeout recommendations
• See individual tool documentation for specific timeout guidance