- onNavigateBack/Forward now skip entirely when currentView === 'workbench'
(user relies on close button, not mouse back)
- onNavigateBack inside workspace checks upBtn.disabled before clicking —
in root folder (no currentPath) button exists but disabled, so navigateBack
falls through to navigationStack for cross-view navigation
- mouseHistoryDirection and keyHistoryDirection also block 'workbench' to
prevent bypass via pointerdown/mousedown listeners
- onNavigateBack/Forward now check for currentView === 'workspace' first
and delegate to Files plugin's up/forward buttons (breadcrumb/Fwd nav)
- Fall back to navigationStack for cross-view navigation
- Removed mouse_monitor.go (xinput test-xi2) — causes phantom X windows,
superseded by GTK-level vendor patch
- Removed startMouseMonitor call from App.Startup
WebKitGTK does not propagate XButton1/XButton2 (buttons 8 and 9) into
DOM events — event.button and event.buttons are always 0 for these
clicks. This prevents the frontend from detecting hardware back/forward
mouse buttons for history navigation.
Solution: patch Wails' window.c on Linux to intercept button-press-event
at the GTK signal level (before WebKit processes it). For button 8/9 we
call webkit_web_view_run_javascript() to dispatch a native CustomEvent
('verstak:navigate-back' / 'verstak:navigate-forward') into the page,
allowing the frontend to navigate history without any workaround on the
JS side.
The patch is applied automatically during build via scripts/build.sh:
go mod vendor → patch -p0 < patches/window.c.button-press.patch
Vendor directory is gitignored.
- Add api.backend.call(method, ...args) to VerstakPluginAPI for direct Wails method invocation
- Add wsName() helper in WorkspaceTree.svelte with String() coercion to prevent [object Object] display
- Use correct Wails path window['go']['api']['App'] in backend.call()
Root cause fixes:
- Sidebar: handleSidebarItem used item.id instead of item.view for viewId.
Platform Test sidebar item has id=verstak.platform-test.sidebar but
view=verstak.platform-test.diagnostics. Click now dispatches correct viewId.
- PluginManager: EnablePlugin/DisablePlugin only wrote to plugins.json but
never re-discovered plugins. UI showed stale state (no Enable button after
Disable, no Disable after Enable). Now calls ReloadPlugins() + loadAll()
after each toggle.
- PluginManager: loadAll() fired async loads (GetCapabilities etc) without
awaiting — loading spinner disappeared before data was ready. Now awaits
all via Promise.all.
- PluginCard: no loading feedback on Enable/Disable buttons. Added
actionFeedback prop — buttons show '⟳ Enabling...' / '⟳ Disabling...'
and are disabled during operation.
- PluginManager: no visible result after Reload/Enable/Disable. Added
toast notifications (success/error/info) with auto-dismiss.
- Settings: openSettingsFromProps didn't handle missing panel — now shows
visible error in modal.
- runContributionsTest rewritten: shows exact manifest fragment from plugin.json
- Capability resolution gates contribution registration (status=degraded)
- Unregister before Register throughout (matches ReloadPlugins)
- Verify contributions by name with data matching manifest
- Proper \n formatting
mirivlad
mirivlad