Environment

• wmux: v0.8.7
• Shell: WSL / any shell running tmux

Behavior

Two related bugs occur when a browser pane (split-tree webview) is open alongside a terminal running tmux:

1. Mouse wheel scroll is stolen by the webview compositor

When a <webview> element is present in the Electron window, Chromium routes un-prevented wheel events to the webview compositor instead of the terminal. The existing wheel handler correctly falls through on the alternate buffer (so xterm can handle it natively), but with a webview present that fall-through means the scroll event goes to the webview rather than tmux.

This is distinct from the general alternate-buffer regression tracked in #41 — it only occurs when a browser pane is simultaneously open.

2. tmux does not redraw after browser pane close / terminal remount

When the browser pane is closed, React remounts the terminal component. tmux doesn't re-send its mode-switching escapes (\x1b[?1049h) on SIGWINCH — it only does so on a fresh client attach. After remount, xterm.buffer.active.type reads 'normal' even though tmux is still running, causing:

• The wheel handler to use the wrong scroll path
• terminal.refresh() in the ResizeObserver to fire unconditionally, painting stale buffer content before tmux's own SIGWINCH redraw arrives, leaving the terminal visually corrupted

Additionally, if the ResizeObserver fires before the pty.create IPC resolves (e.g. on fast remount), the resize event is silently dropped and tmux never receives SIGWINCH at all.

Expected behavior

• Mouse wheel scrolls tmux content when a browser pane is open
• Terminal redraws correctly after browser pane close / component remount

Notes

This is complementary to #41 / PR #42, which fix the general alternate-buffer scroll regression. This issue specifically requires handling the webview-compositor interception case.