[Bug]: OSC 8 hyperlinks show confirmation dialog but do not open browser

[laurencewalshe]

Environment

• App: Wave Terminal
• OS: macOS 14.5 (arm64)
• Default browser: Chrome
• Shell: zsh 5.9

Summary

OSC 8 terminal hyperlinks render correctly and trigger Wave's "dangerous link" confirmation dialog, but clicking OK does not open the URL in the system browser. In the same environment, cmd-clicking a bare URL works as expected, and OSC 8 links work correctly in iTerm2.

Steps to Reproduce

1. Open a local terminal in Wave.
2. Run:

   printf '\e]8;;https://example.com\aClick me\e]8;;\a\n'

3. Click the rendered Click me hyperlink.
4. In the Wave confirmation dialog:

   Do you want to navigate to https://example.com?
   WARNING: This link could potentially be dangerous

5. Click OK.

Actual Result

• The confirmation dialog closes.
• No browser window/tab opens.
• No visible error is shown.

Expected Result

After clicking OK, Wave should open the URL (https://example.com) in the default system browser (same behavior as cmd-clicking a bare URL in Wave, or as OSC 8 in iTerm2).

Additional Notes

• Cmd-clicking a plain URL like https://example.com in Wave successfully opens Chrome.
• Running open https://example.com from the same terminal also opens Chrome.
• Running the same OSC 8 printf command in iTerm2 opens the browser directly (no confirmation dialog, URL opens successfully).
• This suggests the OSC 8 click handler in Wave correctly parses the hyperlink and shows the dialog, but doesn't complete the final step of invoking the system browser.

[ninowalker]

I traced tis further... I will attempt a patch and report back with a PR if this yields a solution.

Wave version: 0.14.5 (macOS)

Clicking an OSC 8 hyperlink in the terminal pops the Do you want to navigate to <url>? confirmation dialog, but pressing OK does nothing — the link never opens.

Plain-text URLs (auto-detected by Wave's own web-link provider) open correctly. Only escape-sequence (OSC 8) hyperlinks are affected, because they take a different code path inside xterm.

Root cause

Wave constructs the xterm Terminal with linkHandler: null (the xterm default) and never sets one. For OSC 8 links, xterm's internal OSC link provider activates via linkHandler ? linkHandler.activate(...) : <xterm default>. With linkHandler null, it falls back to xterm's built-in default handler, which is broken under Electron.

1. xterm default handler — node_modules/@xterm/xterm/lib/xterm.mjs (minified Ol):

function Ol(s, t) {
  if (confirm(`Do you want to navigate to ${t}?\n\nWARNING: This link could potentially be dangerous`)) {
    let i = window.open();          // ← opens about:blank; the URL is NOT passed
    if (i) { try { i.opener = null } catch {} i.location.href = t }
    else console.warn("Opening link blocked as opener could not be cleared")
  }
}

2. Wave's window-open handler — app.asar › dist/main/index.js:

tabView.webContents.setWindowOpenHandler(({ url, frameName }) => {
  if (url.startsWith("http://") || url.startsWith("https://") || url.startsWith("file://")) {
    shell.openExternal(url);
  }
  return { action: "deny" };        // always denies
});

The chain:

1. Ol calls window.open() with no argument → the URL Electron sees is about:blank.
2. about:blank fails the http/https/file prefix check, so shell.openExternal is never called, and the handler returns { action: "deny" }.
3. window.open() therefore returns null, so Ol takes its else branch → silent console.warn.
4. Net result: the dialog appears, you confirm, and nothing happens.

Why plain-text URLs work but OSC 8 links don't

Wave routes every other external link through its own api.openExternal(url) bridge (the terminal hover "Open in External Browser" button, web-view links, docs links, etc.). Only the OSC 8 link path is left on xterm's default linkHandler: null, so it never reaches openExternal.

Suggested fix

Wave already has the right primitive — it just needs to give xterm a linkHandler instead of leaving it null, so OSC 8 links use the same external-open path as everything else:

new Terminal({
  // ...existing options
  linkHandler: {
    activate: (_event, uri) => { getApi().openExternal(uri); },
    // optional: allowNonHttpProtocols, hover, leave
  },
});

This makes OSC 8 hyperlinks open via openExternal and ensures xterm's confirm() / window.open() default never runs.

[nino-robotfutures-co]

This analysis proved correct, and I've opened #3384 as a minimally sufficient patch.