KEY FIX: WebKit's GdkWindow receives all pointer events. Connecting
button-press-event on the GtkWindow never fires. Must connect on the
WebKitWebView widget itself (the Wails pattern).
C library now:
- Walks widget tree to find deepest child (WebKitWebView)
- Connects button-press + motion-notify on the WebView
- Does hit-test in C (8px border zone)
- Calls gtk_window_begin_resize_drag with real event data
- Returns TRUE to consume border clicks, FALSE for interior
- agor_resize.c: C library with GTK signal handlers for resize
- native-resize.ts: Bun FFI wrapper for libagor-resize.so
- resize-test.html: minimal stub for isolating resize behavior
- index.ts: native resize disabled pending stability testing
- RESIZE_TEST env var for loading stub page via Vite
New: agor-pty/native/agor_resize.c — C shared library that:
- Connects button-press-event on GtkWindow + WebView children in C
- Stores mouseButton, xroot, yroot, dragTime from real GTK events
- Exports agor_resize_start(edge) for Bun FFI
Build: gcc -shared -fPIC -o libagor-resize.so agor_resize.c $(pkg-config --cflags --libs gtk+-3.0)
New: ui-electrobun/src/bun/native-resize.ts — Bun FFI wrapper
App.svelte: simplified to just edge detection + RPC call
Motion handler crashes in Bun's JSCallback FFI bridge — disabled.
CSS handles provide cursor feedback. GTK button-press-event handles
actual resize via begin_resize_drag with real event timestamp.
Bundler issue resolved: syntax error in /* */ comment was preventing
Electrobun's bundler from compiling gtk-resize.ts.
Fixed malformed block comment that prevented bun bundler from compiling.
Switched from TypedArray.buffer to Buffer.alloc for FFI output pointers.
Disabled motion handler to isolate button-press resize.
NOTE: Electrobun's dev command rebuilds the bundle on every run, overwriting
manual builds. To test changes, run: bun build src/bun/index.ts --outfile
build/.../app/bun/index.js --target=bun --external=electrobun AFTER
electrobun dev finishes building, then restart the app.
All previous approaches failed because they initiated resize from JS
(too late, wrong timestamp, WebKit steals grab). The correct approach
(proven by Tauri/tao) is to connect button-press-event DIRECTLY on the
GtkWindow at the GTK level, BEFORE WebKitGTK processes events.
New: gtk-resize.ts
- JSCallback for button-press-event + motion-notify-event
- Hit-test in 8px border zone (same as tao's 5*scale_factor)
- begin_resize_drag with REAL event timestamp (not GDK_CURRENT_TIME)
- Returns TRUE to STOP propagation (WebKit never sees the press)
- Cursor updates on motion-notify in border zone
Removed: all JS resize handles (divs, mousemove, mouseup, RPC calls)
Replaced entire FFI chain (XMoveResizeWindow, begin_resize_drag,
XUngrabPointer) with standard browser APIs window.resizeTo + window.moveTo.
Proven to work in Chromium --app mode with same JS resize logic.
Frame captured synchronously via window.screenX/Y + outerWidth/Height.
Zero RPC, zero FFI, zero GTK involvement.
