wasm-gui XU5: Thunar block PINPOINTED to gtk_image_new_from_file("") empty-path hang + deterministic build fix

TWDBG window-init trace: ... -> e menus -> e2 "before sidepane gtk_image_new_from_file" = LAST
LINE, no e3. So thunar-window.c `gtk_image_new_from_file ("")` (an empty placeholder image) HANGS
(~75s, never returns). Platform/runtime edge case, not Thunars fault: gtk_image_new_from_file("")
-> gdk_pixbuf_new_from_file("") -> the runtime opens path "" to sniff the format, and the
empty-path VFS open apparently hangs instead of returning ENOENT. Likely fix = the kernel VFS
returns ENOENT immediately for an empty path (platform layer, constraint #5).

Also fixed the flaky Thunar build for good: replaced `make distclean` with a direct clean (no
`make`), because the prior Makefile has AM_MAINTAINER_MODE on -> `make` tries to regenerate
Makefile.in via the wrong-version automake and wipes them. Direct clean + unconditional tarball
restore = deterministic build.

XU0-XU4 DONE; XU5 block pinpointed to the empty-path open hang. Next: minimal repro + VFS fix.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: NathanFlurry

experiments/wasm-gui/M8-STATUS-LOG.md

@@ -122,3 +122,4 @@
 2026-06-25T18k (XU5 Thunar: builds + gate fix applied + runs NO-TRAP; remaining = GtkApplication-activation block): applied the file-view gate fix to Thunar (build-thunar.sh: compile gio-vfs-local-shim.o + GTKTRANS + -Wl,--wrap=g_vfs_get_default, same as xfdesktop). BUILD RECOVERY: the shared tree had lost Thunar's 24 Makefile.in (untracked dist files; host automake 1.18.1 vs the source's autoconf 2.71 mismatch blocks autoreconf, and Thunar needs XDT m4) -- restored them from third_party/thunar.tar.bz2 (a dist tarball with the Makefile.in, like the whiskermenu plugin.cpp recovery). Thunar 4.18.10 then builds rc=0 -> thunar.wasm 16.3MB. Wrote scripts/test-xu5-thunar.sh (xfwm4 + thunar browsing a /root home folder with files + Adwaita icons + the no-gtk-theme settings.ini lesson from XU4). RESULT: Thunar runs with NO g_vfs_get_default unreachable trap (the gate fix holds), but the window does NOT map -- the separate Thunar GtkApplication-ACTIVATION block. Characterized: Thunar reaches GtkApplication startup (Gtk-DEBUG "Connecting to session manager"; the GNOME/Xfce/inhibit session proxies fail benignly) + the volume-monitor init, then IDLES (last line = GIO_USE_VOLUME_MONITOR='null' can't-find-module warning), no activate/command-line -> window, spins=0 (NOT a busy-hang), 0 X CreateWindow. The minimal gtkapp-probe DID map a window, so this is Thunar-specific. SUSPECTS: (a) the GtkApplication primary-instance DBus name acquisition (g_bus_own_name async) not advancing the activation; (b) Thunar blocking on the volume monitor (xfdesktop emits the same 'null' warning but doesn't use the volume list; Thunar's window side-pane does). NEXT: diagnose the activation (does Thunar own org.xfce.Thunar? does activate/command_line fire?) -- try a working/registered null GVolumeMonitor, or check the g_bus_own_name completion delivery. XU0-XU4 DONE; XU5 build+gate done, activation block remains.
 2026-06-25T18l (XU5 Thunar activation block narrowed HARD: all GENERIC GtkApplication/GIO paths work -> block is Thunar-specific): built guest-xclient/gtkapp-cmdline-probe.c -- a minimal GtkApplication that replicates Thunar's exact path (G_APPLICATION_HANDLES_COMMAND_LINE + the "command-line" signal + g_volume_monitor_get + g_volume_monitor_get_mounts + a window + SYNC and ASYNC g_file_enumerate_children of "/"), built with the gio-vfs-local wrap. RESULT: the probe COMPLETES EVERYTHING: command_line FIRED (cwd=/), volume monitor returned (0 mounts), window SHOWN, SYNC enumerate = 21 entries, ASYNC enumerate COMPLETION FIRED (err=none). So ALL of: the HANDLES_COMMAND_LINE activation path, the DBus name acquisition, the volume monitor, X window mapping, and sync+async folder enumeration WORK in wasm. Therefore the Thunar window-no-map block is NOT a generic GTK/GIO limitation -- it is in THUNAR's OWN code. Read thunar_application_startup (runs before the command-line handler): prime suspects = thunar_preferences_get() (the xfconf-backed prefs -- a blocking xfconf/DBus read), thunar_application_dbus_init() (registers org.xfce.FileManager + org.freedesktop.FileManager1 on the session bus), thunar_session_client_new() (XSMP/ICE session client). The G_MESSAGES_DEBUG run's last line before Thunar idled was the g_volume_monitor_get 'null' warning, but the cmdprobe proves that call itself is fine -> the idle is just after it, in Thunar-specific init. NEXT (decisive): add temporary printf instrumentation to thunar_application_startup + thunar_application_dbus_init (diagnosis-only, revert -- the whiskermenu pattern) to find the exact blocking step. cmdprobe is kept as a reusable GtkApplication/GIO-path harness. XU0-XU4 DONE; XU5 builds + gate-fixed + runs no-trap; the activation block is now isolated to Thunar's own startup.
 2026-06-25T18m (XU5 Thunar block PINPOINTED to the ThunarWindow constructor): added temporary printf instrumentation (TADBG, the whiskermenu pattern, to be reverted) to thunar_application_startup + command_line + process_filenames + open_window. TRACE: startup s0->s6 ALL COMPLETE (preferences, dbus_init, parent startup, session_client, accel idle, css) -> command_line FIRED (cwd=/) -> process_filenames enter (wd=/, first=.) -> open_window: "g_object_new(THUNAR_TYPE_WINDOW)..." <- LAST LINE, no "ThunarWindow created" after it. So the block is INSIDE the ThunarWindow constructor (g_object_new of THUNAR_TYPE_WINDOW -> thunar_window_init/constructed), which builds the whole window UI (menubar/toolbar, the side pane = ThunarShortcutsPane/TreePane + the volume monitor + bookmarks + trash, the main folder view, location bar, statusbar). NOT the startup, NOT the command-line/activation, NOT the volume monitor or enumeration in isolation (the gtkapp-cmdline-probe proved all those work). SUSPECTS inside thunar_window_init: the side pane's trash (trash:// needs the gvfs trash backend, which is --disable-gvfs'd + no dlopen), the bookmarks file read, or a view/model construction. ALSO FIXED this turn: build-thunar.sh now restores the 24 Makefile.in/config.h.in from third_party/thunar.tar.bz2 UNCONDITIONALLY before configure (the shared-tree churn removes an arbitrary SUBSET; a top-level-only check missed subdir losses -> "cannot find input file: Makefile.in"). NEXT: instrument thunar_window_init / thunar_window_constructed to find the exact blocking widget/model. XU0-XU4 DONE; XU5 block now isolated to the ThunarWindow constructor.
+2026-06-25T18n (★ XU5 Thunar block PINPOINTED to gtk_image_new_from_file("") -- an EMPTY-PATH hang): drilled into the ThunarWindow constructor with TWDBG markers. TRACE: init s0 -> a providers -> b/c/d device_monitor+action_mgr -> e menus -> e2 "before sidepane gtk_image_new_from_file" <- LAST LINE, no "e3 sidepane image done". So the block is thunar-window.c's `window->sidepane_preview_image = gtk_image_new_from_file ("")` -- gtk_image_new_from_file with an EMPTY string "" HANGS (it had ~75s after e2 and never returned). This is a platform/runtime edge case, NOT Thunar's fault (Thunar legitimately passes "" to create an empty placeholder image): gtk_image_new_from_file("") -> gdk_pixbuf_new_from_file("") -> the runtime opens path "" to sniff the format, and open("")/the empty-path VFS lookup apparently hangs instead of returning ENOENT. Likely fix = the kernel VFS must return ENOENT immediately for an empty path (a platform-layer fix, constraint #5). ALSO FIXED the flaky Thunar build for good: replaced `make distclean` with a DIRECT clean (find -name Makefile -delete + rm config.status/.o/.libs), because the prior build's Makefile has AM_MAINTAINER_MODE on -> `make <target>` first tries to regenerate Makefile.in via the wrong-version host automake and WIPES them -> "cannot find input file: Makefile.in". The direct clean (no `make`) + the unconditional tarball restore makes the build deterministic. NEXT: minimal repro (a probe calling open("") and/or gtk_image_new_from_file("")) to confirm the empty-path hang, then fix the VFS empty-path open in the runtime. XU0-XU4 DONE; XU5 block pinpointed to the empty-path open hang.

experiments/wasm-gui/scripts/build-thunar.sh

@@ -35,7 +35,13 @@ fi
 CFG_SUB="$(ls "$TP"/libX11-threads/config.sub 2>/dev/null | head -1)"
 CFG_GUESS="$(ls "$TP"/libX11-threads/config.guess 2>/dev/null | head -1)"
 for d in . build-aux; do [ -d "$d" ] && cp "$CFG_SUB" "$CFG_GUESS" "$d/" 2>/dev/null || true; done
-make distclean >/dev/null 2>&1
+# Direct clean instead of `make distclean`: the prior build's Makefile has AM_MAINTAINER_MODE on, so
+# `make <anything>` first tries to regenerate Makefile.in from Makefile.am via the host automake (wrong
+# version) and WIPES the Makefile.in -> configure then fails "cannot find input file: Makefile.in". Remove
+# the generated files directly (no `make`), so the restored Makefile.in survive into configure.
+find . -name Makefile -type f -delete 2>/dev/null
+rm -f config.status config.cache config.log thunar/thunar 2>/dev/null
+find . -name '*.o' -delete 2>/dev/null; find . -name '.libs' -type d -exec rm -rf {} + 2>/dev/null
 export CC="$EXP/toolchain/clang-wasi-wrap.sh"
 export CFLAGS="$CFLAGS -I$PREFIX/include -g0"
 export LDFLAGS="$LDFLAGS -L$PREFIX/lib -lhostcompat"