fix(find): the find widget's tooltips stop being clipped away (#675)

[PathGao]

What this is

Closes #675, reported by @khbbkhbk with two screenshots: hovering any button in the first row of the editor's find/replace bar (Ctrl+F / Ctrl+H) either showed a sliver of a tooltip or one that flickered while the pointer sat still. The second row was fine.

Tooltips on that row are now fully visible, drawn over the tab-bar strip the way VS Code draws them over its tabs, and they no longer overlap the button that summoned them.

Mechanism

Monaco's find widget draws its button tooltips through the hover service, which appends a .context-view next to the editor and places it above the target. hoverWidget.js's adjustVerticalHoverPosition flips one below only when the tooltip would leave the window — measured in viewport coordinates, not against the editor. The widget sits a title bar's height down (36px here, tooltip ~25px), so the check passes with ~10px to spare, the flip never fires, and the tooltip lands at y≈14–39: inside the strip .pane and .editor-outer clip with overflow: hidden, and behind .custom-title-bar, which is position: fixed; z-index: 9999 against the inline z-index: 2576 Monaco writes on the context view.

Both had to go, or the tooltip is clipped in one case and painted under the title bar in the other. The second row was never affected because its tooltip fits inside the pane.

Measured on the reporter's configuration (editor toolbar hidden, so the widget hugs the pane's top edge), by hit-testing the tooltip box with elementFromPoint:

	tooltip top	middle	bottom
before	title bar	title bar	hover-contents
after	hover-contents	hover-contents	hover-contents

"Close (Escape)" now renders on one line, 103×25 at y13–38, clear of its button at y41–63 — that overlap is what the reported flicker was: the tooltip covered the button, the pointer entered the tooltip, the button's mouseleave hid it, and the cycle repeated.

Scope

overflow: visible rather than overflow: clip with an overflow-clip-margin, which would bound the escape more tightly: per MDN's compat data WebKit ships clip with version_added: false for the margin property, so that spelling degrades to a plain clip — a silent no-op on the macOS and Linux builds. clip-path: inset(-48px 0 0 0) expresses the intent exactly and fails differently: it creates a stacking context, trapping the tooltip below the title bar it has to paint over.

Letting the panes go visible unconditionally would risk content spilling sideways during the pane's flex/opacity transitions, when Monaco's layout lags the animation — hence :has(.find-widget.visible). It turns out to be belt-and-braces: Monaco keeps its content and the find widget itself inside .overflow-guard, so .context-view is the only child that can paint outside at all.

Not touched: the preview's own find bar (FindBar.svelte), which has its own tooltips and never had this problem; and the underlying limitation, which is that standalone Monaco mounts hovers in the editor's container rather than at the document root. Replacing the editor's find UI with the app's own find bar would settle both, and is a feature, not this fix.

Tests

scripts/findWidgetTooltipClip.test.ts, two source-shape assertions. Revert either half of the fix and both go red — checked by flipping overflow: visible back to hidden and dropping the z-index below the title bar's.

The first anchors the CSS declaration, including the :has() scoping. The second is the one worth having: it reads .context-view's z-index out of src/styles.css and .custom-title-bar's out of TitleBar.svelte and asserts the first is larger. That coupling spans two files and nothing else records it — raise the title bar and the tooltips silently go back under it.

scripts/exportFoldParity.test.ts needed one change to accept the new CSS: its hand-rolled selector matcher answered 'unsupported' for any compound containing an unmodelled :, and three export-fold assertions turn 'unsupported' into a failure. :has() now gets the treatment :nth-* already had — stripped before the shape check, so a rule keyed on classes this element doesn't carry is still decided outright, and only a compound that otherwise matches has to admit it can't tell. The existing :has() rules in the sheet were never hit by this because they all contain [, which the matcher rejects earlier.

Verification

npm audit             0 vulnerabilities
npm run check         801 files, 0 errors, 0 warnings
npm test              924 pass, 0 fail
npm run test:vitest   41 files, 365 pass
cargo test            148 pass

Behaviour was measured in Chromium, against the dev server with window.__TAURI_INTERNALS__ stubbed so the frontend boots outside Tauri — that covers the WebView2 build the report came from, and it is why overflow-clip-margin was ruled out by compat data rather than by running it.

Also run from a local release build on macOS 26.5 (WKWebView): first and second row, toolbar shown and hidden, split view. Not run on Linux/WebKitGTK, and not on Windows itself — the reporter's exact platform is covered by reasoning plus the Chromium measurements, not by a run.