.window's 6px radius and its outer drop shadow are painted by the webview
OUTSIDE the window's own rectangle, so on an opaque surface they were simply
clipped — square corners, no shadow. chromeOptions now passes
`transparent: true`, the page paints no background of its own, and .window
takes a 6px margin as the gutter the shadow falls into (h-screen shrinks by the
same amount so the gutter does not produce a scrollbar).
Confirmed on Linux/WebKitGTK in a real run, which is the half the Firefox
harness cannot model:
GTK: Created window without decorations (custom titlebar)
GTK: Created transparent window
GTK WebKit: Applied transparent background to webview
Also caught by the run rather than shipped: `transparent` is set in
chromeOptions, which openSecondaryWindow spreads too — so the editor and
connection-manager windows became transparent while still rendering bare
content, i.e. floating widgets on nothing. Both roots now take the same
.window.glass frame and their own windowFocused signal. The editor's blur
binding had to merge with the existing flushDraft() call; a duplicated host key
is a TS1117 build error rather than a merge, which is how it surfaced.
The old anti-flash <style> in index.html is gone with the opaque backgrounds it
guarded — windows are created hidden and revealed on dom-ready anyway.
Not handled yet: a maximized Win7 window has no radius, shadow or gutter. The
6px margin currently applies in every state.
Co-Authored-By: Claude <noreply@anthropic.com>
jgamboaandClaude
fe75904872