Site adapters fail with 'Failed to fetch' while eval works fine

[osen77]

Environment

• bb-browser: v0.8.0
• Chrome: 145 (macOS)
• OS: macOS (Apple Silicon)
• Network: Clash TUN mode (system-wide proxy)
• Mode: Standalone (Chrome extension + daemon)

Bug Description

Site adapters consistently fail with TypeError: Failed to fetch, but running the exact same fetch() call via bb-browser eval works perfectly. This suggests a difference in the execution context between site adapters and eval.

Steps to Reproduce

1. Install bb-browser, load Chrome extension, run bb-browser site update
2. Verify extension is connected: bb-browser status → "浏览器运行中"
3. Run any site adapter:

$ bb-browser site hackernews/top 3
[error] site hackernews/top: Uncaught (in promise) TypeError: Failed to fetch
  Hint: Open https://news.ycombinator.com in your browser, make sure you are logged in, then retry.

4. Run the exact same fetch via eval — works fine:

$ bb-browser eval "fetch('https://hacker-news.firebaseio.com/v0/topstories.json').then(r=>r.json()).then(ids=>ids.slice(0,3))"
[47392084, 47390817, 47390945]

Additional observations

• The first site hackernews/top call after installing the extension succeeded and returned valid JSON data
• All subsequent calls fail with the same error
• Tested multiple adapters (hackernews/top, baidu/search, zhihu/hot) — all fail identically
• bb-browser eval "fetch('https://httpbin.org/get').then(r=>r.json())" also works fine
• Switching to the target tab first (bb-browser tab 3) does not help
• Restarting the daemon does not help
• Tab listing works, browser status reports connected

Expected behavior

Site adapters should execute fetch() in the same page context as eval, and return data successfully.

Suspected cause

Site adapter code appears to run in a different execution context (extension Service Worker? isolated world?) compared to eval, where fetch() fails — possibly due to CORS, CSP, or Chrome MV3 Service Worker restrictions.

[osen77]

Update: Root cause identified

After further debugging, the issue is CORS/CSP restrictions in page context.

Evidence:

• Same-origin fetch works: bb-browser eval "fetch('https://news.ycombinator.com/').then(r=>r.status)" → 200
• Cross-origin fetch fails: bb-browser eval "fetch('https://hacker-news.firebaseio.com/v0/topstories.json').then(r=>r.status)" → TypeError: Failed to fetch

The hackernews/top adapter calls fetch('https://hacker-news.firebaseio.com/v0/topstories.json') which is cross-origin relative to news.ycombinator.com. Since eval and site adapters execute in the page context, they inherit the page's CSP and CORS restrictions.

The first successful call likely ran on an about:blank tab (no CSP), which is why it worked initially but failed on subsequent attempts (after bb-browser opened an actual HN tab to reuse).

Possible fix: Site adapters that use cross-origin fetch() could execute in the extension's Service Worker context (which has broader network permissions) instead of the page context, or use chrome.runtime.sendMessage to proxy the fetch through the background script.

[osen77]

Fix submitted: #45

After deeper investigation, the root cause is simpler than initially thought:

The real architecture (v0.8+): bb-browser connects directly via CDP WebSocket to a managed Chrome instance — the daemon+extension SSE architecture described in earlier docs is no longer used. Runtime.evaluate runs adapter JS in page context, where cross-origin fetch() is blocked by CORS/CSP.

The fix: Adapters that declare capabilities: ["network"] in their metadata now execute directly in the Node.js CLI process via new Function(). Node's fetch() has no CORS restrictions, so cross-origin API calls (Firebase, V2EX API, etc.) succeed without needing browser context.

Adapters without "network" capability continue to run via CDP in page context, preserving cookie-based authentication for login-required sites.

Tested successfully with hackernews/top and v2ex/hot.