[Bug] Sidebar browser stays blank when the dsh UI runs inside a guest webview (iframe fallback, no error shown)

[furkancak1r]

Summary

The built-in sidebar browser ("Browser" tab in the right sidebar) stays blank for most sites when the dsh web UI runs inside a guest <webview> in the desktop app. No error shows.

Example: a plugin shows the dsh web UI of a different computer (remote host) inside a <webview>. In that view, https://github.com/ stays blank. https://example.com/ and a plain local page load correctly.

Steps to reproduce

1. In the desktop app, show the dsh web UI of a remote host inside a guest <webview> (for example with a plugin).
2. In that view, open the "Browser" tab in the right sidebar.
3. Go to https://github.com/.

Expected

The page loads, as it does in the sidebar browser of the local desktop UI. If the page cannot load, the panel shows an error and points to "Open in system browser".

Actual

The panel stays blank and shows no error. The iframe navigation fails with net::ERR_BLOCKED_BY_RESPONSE (-27).

Cause

Line numbers are approximate and refer to the bundled files in app.asar of 0.2.2-rc.1. The same code is on master (e8f7b93).

1. The sidebar browser uses the desktop <webview> mode only when globalThis.dshDesktop.browser exists. If it does not exist, the panel falls back to an <iframe> (web mode).
   • Bundle: dsh-client-ui-sidebar-browser/lib/client.js, approximately lines 1771-1813 (mode select) and 968-974 (iframe).
   • Source: packages/client/ui-sidebar-browser/src/client/index.ts and src/client/view/IframePresentation.ts.
2. A dsh UI inside a guest webview never gets that bridge:
   • The preload exposes the full dshDesktop bridge only to the main frame of dsh-app://app. Other pages get { protocolVersion: 1 } without browser (lib/preload-app.cjs, approximately line 1976, source apps/desktop/src/preload-app.ts).
   • For guest webviews, will-attach-webview deletes all preferences except disablePopups, so the guest gets no preload (lib/main.js, approximately line 18671, source apps/desktop/src/browser-guests.ts).
3. Sites that send X-Frame-Options or a CSP frame-ancestors directive cannot load in the iframe. github.com sends X-Frame-Options: deny and frame-ancestors 'none'. The iframe still fires load, so the panel records a successful load and shows no error.
4. Inference from code reading (not tested): a localhost URL in the remote view loads in the iframe of the local renderer. Thus it opens on the local computer, not on the remote host.
5. Inference (not tested): plain dsh web in a normal browser also uses the iframe mode, so the missing error probably occurs there too.

Suggested fix

1. Detect a blocked iframe load, because load fires anyway. For example, let the Host check X-Frame-Options and CSP frame-ancestors before the load. Then show an error with the "Open in system browser" action.
2. Give the sidebar browser a supported way to use the desktop browser bridge when the dsh UI runs inside a trusted guest webview. For example, the owner window can host the browser guest for it. Guests get webviewTag: false, and the main process blocks nested will-attach-webview (lib/main.js, approximately line 18724). Thus this change needs main-process support. If this is out of scope, document the limit.

Workaround

• Use the "Open in system browser" button in the sidebar browser toolbar.
• Use the sidebar browser of the local desktop UI.

Related: #9909 (public native sidebar browser APIs), #12670 (desktop remote host mode), #11987 ("Open in system browser" does nothing in some setups).

Environment

• DeepSeek Harness desktop 0.2.2-rc.1
• Electron 44.7.0
• macOS 27.0.1