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.
begin_resize_drag + XUngrabPointer still fails because GTK's layout
cycle re-asserts WebView preferred size, fighting the WM resize.
New approach: JS mousemove → XMoveResizeWindow via libX11.so.6 FFI.
Completely bypasses GTK size negotiation. GTK only receives
ConfigureNotify after the X server has already resized the window.
Added: x11SetFrame() using gdk_x11_display_get_xdisplay +
gdk_x11_window_get_xid + XMoveResizeWindow.
Root cause confirmed via X11 research: WebKitGTK holds an implicit X11
pointer grab from button-press. GTK's gdk_seat_ungrab targets the wrong
device, leaving the grab active. Mutter gets AlreadyGrabbed and gives up.
Fix: call XUngrabPointer(xdisplay, CurrentTime) + XFlush directly via
libX11.so.6 FFI before begin_resize_drag. This releases ALL grabs on
the display connection, matching SDL2's proven approach.
Removed failed approaches: WebView sensitivity toggle, findWebView cache.
Codex review #3 identified: the issue is NOT min-size but pointer grab
conflict. WebKitGTK steals the WM's X11 pointer grab when cursor enters
the WebView during inward resize.
Fix: gtk_widget_set_sensitive(webview, false) before begin_resize_drag,
re-enable after 5s. Also added findWebView() to cache the deepest
GtkBin child pointer for fast access.
Codex review #2 found: set_size_request only controls minimum, not
natural/preferred size. WebView still reports content size as natural,
causing rubber-band effect during shrink.
Fix: reparent WebKitWebView into GtkScrolledWindow via FFI with
propagate-natural-width/height=FALSE and min-content=1x1. This
decouples WebView content size from window size negotiation.
Also reverted to native begin_resize_drag (WM handles everything).
Electrobun's setSize respects WebView min-size constraint. Bypass it
with direct gtk_window_resize() + gtk_window_move() FFI calls.
clearMinSizeTree() runs on every resize frame to suppress WebView
re-propagation. gtkSetFrame() exported as new RPC endpoint.
GTK begin_resize_drag loses grip when cursor moves inward past the 6px
handle zone. Replaced with document-level mousemove/mouseup listeners
that compute delta from initial frame and call setPosition+setSize.
- clearMinSize RPC clears WebView min-size before resize starts
- Cursor locks to resize direction during drag (body.style.cursor)
- user-select disabled during drag to prevent text selection
- Frame captured async before resize starts (no race condition)
WebKitWebView re-propagates content size as minimum on every layout cycle,
overriding the one-time init fix. Now clearMinSizeTree() runs right before
each gtk_window_begin_resize_drag call, allowing resize-in (shrink).
Also removed red debug background from resize handles.
Root cause: WebKitWebView requests min_size = content_size (5120x1387 on
ultrawide), which GTK propagates to WM_NORMAL_HINTS, blocking all resize.
Fix: recursively walk the GTK widget tree (GtkWindow → GtkBin → WebView)
and call gtk_widget_set_size_request(-1, -1) on every widget. Then set
gtk_window_set_geometry_hints with min=400x300.
Result: WM_NORMAL_HINTS now shows min=10x10, window is fully resizable.
