ASan caught it: heap-use-after-free at wl_clip_icon_paint:8478 reading
workspace->clip->collapsed. The flow is:
wWorkspaceRestoreState()
if (scr->workspaces[i]->clip)
wDockDestroy(scr->workspaces[i]->clip); // frees the WDock
scr->workspaces[i]->clip = wDockRestoreState(); // creates new
wDockCreate -> dockIconPaint -> wClipIconPaint
-> wl_clip_icon_paint
workspace->clip->collapsed // ← reads freed pointer
scr->workspaces[i]->clip is dangling between the wDockDestroy and the
assignment from wDockRestoreState. wl_clip_icon_paint runs inside
that gap (wDockCreate calls dockIconPaint via wClipIconPaint).
Fix: read collapsed state from aicon->dock instead of workspace->clip.
aicon->dock is the dock currently being constructed and is always
valid at this point.
This was masquerading as a 'double free' on right-click of titlebars
(the heap corruption from the early use-after-free corrupted later
allocations that pixman_image_unref then tripped over). Removed
the diagnostic logs added while debugging.
Speculative fix for double-free crash when right-clicking a window
titlebar to open the window menu (WMaker's Options cascade brother
realize). Stack trace shows pixman_image_unref crashing with
'double free or corruption (out)' on a freshly-created 1x10 image.
This commit:
* Saves old_image, creates new fb->image, updates metadata, notifies
wlroots, THEN unrefs old_image — so wlroots' begin_data_ptr_access
only ever sees the new image during the resize transition.
* Adds wwarning logging in wl_frame_configure and the buffer destroy
callback to catch the crash sequence.
Diagnostics will be removed once the root cause is fixed.
E3 (Crash Dialog):
Showing a UI from a crashed compositor's child process is impossible
on Wayland — the child cannot connect to the dead parent's display.
Default to WMRestart instead of WMAbort, so the user's session
recovers automatically on a wmaker crash (the standard daily-driver
expectation). Removed the misleading 'cannot open connection'
message.
E2 (Info Panel) and E4 (Icon Chooser): both already use the standard
fake_leader_create + wManageInternalWindow pattern that the Exit and
Run dialogs use. No code changes; user can verify by opening Info
Panel from the root menu and Icon Chooser via right-click on a dock
icon → Settings → Browse.
Native Wayland clients had no way to be saved across restarts: the
backend's window_get_command vtable slot was a no-op, so session.c's
makeWindowState early-returned NULL for every native client.
Implementation:
* Native XDG client: return [app_id] as single-arg command. Most
app_ids match the binary name (foot, firefox, gedit, etc.) so
plain execvp() during session restore finds them on PATH.
* XWayland client: try WM_COMMAND via wl_state.x_display first
(most reliable), fall back to instance/class.
Limitation: reverse-DNS app_ids (org.gnome.Terminal, etc.) won't
restore — a follow-up patch should add a desktop-file lookup.
Both files implement X11-specific protocols (EWMH _NET_* and XDND).
They were sitting in shared src/ because they predated the backend
split; the only remaining users in shared code were now via
wm_backend-> dispatch.
To get there, four new vtable slots replace the last direct calls
from shared src/:
screen_get_head_usable_area (screen.c was calling wNETWMGetUsableArea)
window_get_icon_image (icon.c was calling get_window_image_from_x11)
netwm_set_frame_extents (window.c, winspector.c were calling wNETFrameExtents)
(window_fetch_name and window_get_icon_name extended to consult EWMH first)
Other changes:
* get_window_image_from_x11 now takes Display* explicitly so the
Wayland backend can pass wl_state.x_display for XWayland clients
instead of relying on a global (which is NULL on Wayland).
* Eight shared .c files lose their now-unused #include "wmspec.h"
or #include "xdnd.h".
* Makefile.am moves wmspec.{c,h} and xdnd.{c,h} into the backend/x11
listing.
* src/Makefile.am drops the obsolete --disable-xdnd Makefile branch
and unconditional sources list still references the new paths.
Final state: every Xlib call in the codebase lives in src/backend/x11/
or src/backend/wayland/. The only remaining "X*(" matches outside
backend/ are six XSetForeground/XDrawLine calls in src/moveres.c
inside an \#if 0 block (dead code; left for now). src/ has zero
_x11_raw references.
Crash on closing a toplevel: handle_toplevel_destroy called
wlr_scene_node_destroy on view->scene_node, but the node had
already been destroyed by wlroots a few stack frames earlier when
the WMaker frame's tree was destroyed (frame_destroy → tree
destroy cascades to children).
Fix: register a destroy listener on view->scene_node when it's
created. When wlroots destroys the node (typically because its
parent tree is destroyed during unmanage), the listener fires and
NULLs view->scene_node, so handle_toplevel_destroy's existing
'if (view->scene_node)' check correctly skips the redestroy.
handle_toplevel_destroy itself removes the listener before its
own wlr_scene_node_destroy call so we don't double-remove the
listener entry from the wlroots signal list.
Multi-head support comes through WScreen.heads[] (populated by the
backend's screen_open) and the wGetRectForHead / wGetUsableAreaForHead
helpers — both backend-agnostic. The USE_XINERAMA #ifdefs in shared
src/ were a build-time toggle for X11-extension presence and did not
belong in policy code.
Strip the guards in:
src/wmspec.c _NET_WM_FULLSCREEN_MONITORS atom now unconditional.
src/actions.c wFullscreenMonitorsWindow now unconditional.
src/dialog.c About-dialog 'Xinerama: N head(s) found' string now
unconditional. (The string still references the X11
extension by name; on Wayland this is somewhat
misleading but cosmetic — proper fix would route
'About' info through the backend.)
USE_XINERAMA remains in src/backend/x11/x11_monitor.c, where it
correctly gates the Xinerama-extension code at build time. The
configure --enable-xinerama option is unchanged.
The XDND-on-dock feature was a configure-time toggle (--disable-xdnd)
gating ~25 #ifdef sites across shared src/. This was a pre-Wayland
feature flag, not a backend distinction, but it polluted the policy
layer with build-time conditionals.
Make it unconditional:
configure.ac Remove --disable-xdnd and AM_CONDITIONAL. XDND on
the dock is always built.
src/Makefile.am Move xdnd.c from the if-USE_DOCK_XDND block into
the unconditional wmaker_SOURCES list.
src/dock.h, dock.c, dockedapp.c, appicon.h, appicon.c, event.c,
misc.c, startup.c, dialog.c, screen.h
Strip all #ifdef USE_DOCK_XDND/#endif pairs. In
dockedapp.c the #else branch (rendering an 'XDnD
support was not compiled in' label) is dead and
removed.
Backend routing: the X11 backend continues to drive the XDND protocol
through xdnd.c via the existing xdnd_process_client_message /
xdnd_process_selection / xdnd_make_awareness vtable slots. Wayland's
slots are no-ops (XWayland clients drop into the X11 path naturally
via wl_state.x_display).
src/ is now free of feature-flag guards related to DnD.
Three more vtable slots that took void* (intended for an XEvent*) widened
to take WMEvent*; the X11 impls extract _x11_raw internally:
event_handle_extensions(WMEvent*)
netwm_process_client_message(WMEvent*)
xdnd_process_client_message(WMEvent*)
Also added a new client_message_forward(WMEvent*, WNativeWindow) slot for
the OffiX DND ClientMessage redirect (icon frame -> real client_win).
The X11 backend rewrites xclient.window and XSendEvent's it; the Wayland
backend does the same on wl_state.x_display for XWayland clients.
After this change, src/event.c contains zero _x11_raw references — the
last X11 escape from the shared event dispatch layer is closed.
XSupportsLocale and XSetLocaleModifiers in main.c were the last
direct Xlib calls in src/main.c. Move them into x11_display_open
(guarded by I18N) where they naturally belong. The Wayland backend
does not need them — locale handling for native Wayland clients is
just standard libc, and XWayland clients still receive locale-aware
input via the wmaker-attached XWayland server's own setup.
main.c is now Xlib-free.
* usermenu.c notifyClient: replace XSendEvent KeyPress/KeyRelease
synthesis with two wm_backend->client_send_key calls.
* New vtable slot client_send_key(win, keycode, modifier_mask, press).
X11: synthesize XKeyEvent and XSendEvent.
Wayland: same but on wl_state.x_display (XWayland clients). Native
Wayland clients deferred (would need
zwp_virtual_keyboard_v1).
* misc.c: keysymToString was dead code inside #if 0 — removed.
After this change misc.c and usermenu.c carry zero direct Xlib calls.
xmodifier.c contained x_reset_modifier_mapping which walked the X
server's modifier map via XGetModifierMapping / XFreeModifiermap to
discover the X11 modifier indices for Meta/Hyper/Super/Alt keysyms.
This was 4 direct Xlib calls in shared src/.
Refactor:
src/xmodifier.c — now only holds the modifier-mask state and the
portable wXModifierFromKey / wXModifierToShortcut
Label / wSetModifierMasks helpers used by shared
policy code. No more Xlib symbols.
src/backend/x11/x11_backend.c — owns x11_reset_modifier_mapping,
called from x11_extensions_init. Calls
wSetModifierMasks at the end so shared code
answers modifier lookups correctly.
src/xmodifier.h — drops wXModifierInitialize. Wayland never needed
it; X11 calls the local x11_reset_modifier_mapping
directly.
The unused ModeMask static was dropped along the way.
The Window Inspector's 'select window' feature grabbed the pointer on
the root window then read XEvent.xbutton.subwindow to learn which
window was clicked. This was the last access to _x11_raw in shared
src/ code.
Add a subwindow field to WMEButton. The X11 backend's WMEvent
translation populates it from xbutton.subwindow. The Wayland backend
leaves it 0 (Wayland has no equivalent grab semantic — the click
reports the actual frame as event.window directly). winspector.c
now uses event.u.button.subwindow with fallback to
event.u.button.window, working on both backends.
Net: src/ has zero _x11_raw escapes from shared code. Remaining
references are inside the X11 backend (legitimately consuming the
field set by its own event translator).
Five _x11_raw accesses in shared event.c (the worst architectural leak)
removed by widening vtable signatures and moving X11-only logic into
the X11 backend:
WME_SELECTION_REQUEST / WME_SELECTION_CLEAR
* handle_selection_request/clear functions deleted from event.c
* Reimplemented in x11_backend.c as x11_handle_selection_request/clear
where they read _x11_raw internally and call XChangeProperty etc.
* New vtable slots handle_selection_request / handle_selection_clear
(WMEvent*). Wayland: no-ops (wmaker UI does not own a WM_Sn
selection on the X server).
WME_CONFIGURE
* event_randr_update vtable widened to (WMEvent*).
* Root-window check (DefaultRootWindow) moved into x11 impl.
WME_MAPPING
* Dropped the if (xev) guard — keyboard_mapping_refresh already
took WMEvent*.
WME_SELECTION
* xdnd_process_selection vtable widened to (WMEvent*).
Net: event.c is X11-free except for DefaultRootWindow uses elsewhere
that will be cleaned up in subsequent tasks.
A WMenu's brother is a parallel copy of the same menu used when the
menu is torn off / buttoned. The brother shares cascade pointers
that reference back into the original tree, so recursing into both
m->brother and m->cascades[i] cycled (brother->cascades[i] == m's
own cascade entry, which has its own brother, etc.) and overflowed
the stack on any cascaded menu.
Inline the brother hit-test instead of recursing into it. Cascades
themselves are walked recursively as before so sub-sub-menus remain
reachable.
The previous implementation only checked one level of cascades —
scr->root_menu and scr->root_menu->cascades[i]. Sub-sub-menus
(cascade->cascade->...) were never checked, so hovering over a
sub-sub-menu's entries did not return the menu, and selectEntry
therefore could not open the next-level cascade or react to clicks.
Replace with a recursive walk over each top-level menu's full
cascade tree. Pick the deepest mapped menu that contains the
pointer (deeper cascades render on top in the scene graph and
should win the hit-test).
X11 sidesteps this with XQueryPointer + XFindContext, which finds
any menu window via the X server's hit-test regardless of nesting.
wlr_scene_buffer_set_buffer treats same-pointer assignment as a
no-op — pixel updates to fb->image are not picked up. Every paint
function in the backend mutates fb->image (or s->wlr_buf) in place
and then commits with the same pointer, so wlroots never re-rendered
the changed contents.
Convert all 15 sites to wlr_scene_buffer_set_buffer_with_damage(...,
NULL) which forces a full rerender. This restores the menu paint
fix to its proper general form and addresses the clip workspace
number/title not appearing at startup, as well as latent staleness
in dock/drawer icon and balloon paint paths.
wFrameWindowUpdateBorders calls wFrameWindowResize at line 356,
which (since commit f88dfac) calls frame_paint. On X11,
frame_paint dispatches to wFrameWindowPaint which iterates
button descriptors and calls handleButtonExpose. But the
descriptors' parent field is set later in wFrameWindowUpdateBorders
(after the resize call) — so during this first paint, fwin
(desc->parent) is NULL and the function segfaults at the
left_button comparison.
The Wayland backend skips wFrameWindowPaint via wl_frame_paint
returning 1, so it never hit this path.
Top-level frame trees were enabled by default at creation. When
framewin.c then called wm_backend->window_map_raised(titlebar) at
frame creation time (necessary for X11 decoration semantics), the
titlebar's scene_buf became enabled. Combined with the always-enabled
tree, this made the titlebar visually rendered at the frame's
default spawn position — even for menus and dialogs that had not
been logically mapped yet. The visible orphan reflected whichever
submenu titlebar was painted last (e.g. 'Multimedia').
Fix: top-level frame trees now start DISABLED. wl_window_map and
wl_window_map_raised explicitly enable the tree when called on a
top-level frame_buf. This matches X11 semantics where a child window
is only visible if its parent window is mapped. Decoration children
(titlebar, buttons) being individually 'mapped' no longer produces
orphan visibility because the parent frame's tree gates their
visibility.
Frame_bufs that owned a wlr_scene_tree (top-level frames and the
fake_leader for dialogs) leaked their tree on destroy. The scene_buf
was destroyed but the tree remained in the scene graph as an orphan,
causing stale rendering — most visibly as ghost titlebars near the
clip after closing a menu, since the leaked menu frame trees stayed
in the scene.
Several related fixes for WINGs dialogs and menus that depend on
correct scene graph parenting and hit-testing:
1. fake_leader_create: now creates a wlr_scene_tree (not just a
scene_buf). When the fake_leader is reparented into a WMaker frame,
any content inside it (e.g. WINGs panel) is reparented as part of
the tree, so it follows the WMaker frame's position when moved.
2. wl_client_reparent (frame_buf path): if the source frame_buf has
a tree, reparent the tree (with all its children) instead of the
bare scene_buf.
3. frame_buf_update_children_abs: new recursive helper to walk the
entire descendant tree updating fb->x/y absolute tracking. Used
by wl_window_move, wl_frame_configure, and wl_client_reparent.
Without this, grandchildren (e.g. WINGs panel inside a fake_leader
inside a WMaker frame) had stale fb->x/y after the WMaker frame
was moved, causing click coordinate translation to be wrong and
buttons to stop responding after dragging the dialog.
4. frame_buf_button_at: now walks up the scene tree checking ancestor
enabled state. A frame_buf's scene_buf may be flagged enabled even
when an ancestor tree is disabled (e.g. menu unmapped). Without this
check, clicks could be incorrectly routed to ghost frame_bufs from
recently-unmapped menus, causing root-menu reopen to require
multiple clicks.
After shading a window, clicks on the lower titlebar would be routed to
the resizebar handler, requiring multiple clicks before one landed in
a region where frame_buf_button_at didn't return the (disabled) resizebar.
Two related bugs:
1. frame_buf_button_at iterated all child frame_bufs without checking
enabled state. The shaded resizebar's bounds still recorded in
fb->x/y/width/height but its scene_buf was disabled. Since the
shaded resizebar was repositioned ON TOP of the titlebar, clicks
in the overlapping region returned the (smaller, disabled)
resizebar instead of the titlebar. Added an enabled-state check.
2. wlroots scene graph caches buffer dimensions for hit-testing.
Mutating fb->base.width/height directly leaves stale bounds. Use
wlr_scene_buffer_set_dest_size() whenever the buffer is resized.
Also fixes:
- WINGs dialog content was placed in WL_LAYER_FLOATING instead of
under the parent frame's tree, so the content didn't follow the
WM-managed decorations on move. Now parented under the frame tree
and positioned at relative offset.
- wl_window_map called wlr_scene_node_raise_to_top on the client
scene_node, which raised it above the titlebar within the frame
tree. After unshade this hid the titlebar. Removed.
- xdg_activation focus path: raise the frame tree, not the client
scene_node, for the same reason.
The scene graph was using absolute coordinates for all nodes with the
frame tree at (0,0). This caused the resizebar to be detached from the
window frame and resize to break because child nodes (titlebar, client
surface, resizebar) had to be manually repositioned on every move/resize.
Refactor to the correct wlroots model:
- Frame tree positioned at (frame_x, frame_y)
- All children use local offsets relative to the tree
- Moving the tree moves everything automatically
Additionally fix interactive resize:
- handle_toplevel_commit now syncs the WM frame to the client's actual
committed buffer size, ensuring frame and client stay in lockstep
- Ensure client scene_node is always parented under the frame tree
- Simplify wl_window_resize to just send xdg_toplevel.set_size without
blocking event loop dispatch
- Properly free old pixman images and detach stale buffers on resize
1. Resizebar: wl_frame_paint_resizebar was painting a flat color buffer
over the textured resizebar rendered by wl_frame_paint. Make it a
no-op since the parent frame buffer has the correct texture.
2. Resize gap: client_synth_configure updates the client scene_node
position but was not updating frame_rel_x/y. When frame_configure
ran next (e.g. on subsequent move), it would recompute the client
position using stale frame_rel values, causing the surface to jump.
Now updates frame_rel_x/y from the new absolute position.
On X11, resizing a frame triggers an Expose event which repaints the
decorations. On Wayland, no such event is generated, so the frame
(titlebar, resizebar) was never repainted after resize — leaving
stale decorations at the old width.
Call frame_paint after reconfigure in both wFrameWindowConfigure
and wFrameWindowResize.
frame_buf_button_at had a size threshold (width>30 || height>30) that
skipped resizebar frame_bufs during hit-testing. The resizebar is wide
but short (~8px), so it was always skipped. Clicks in the resizebar
area fell through to the parent frame, preventing resize.
Remove the size threshold. The smallest-area heuristic already ensures
buttons (small) are preferred over resizebars (large) when both match.
Client surfaces (e.g. foot terminal) were not updating after initial
map. Two issues:
1. wlr_scene_output_commit(scene_output, NULL) in wlroots 0.19 may
skip rendering if it determines no damage is pending, even when
client surfaces have committed new buffers.
2. Frame scheduling was dependent on host compositor timing.
Fix: Replace wlr_scene_output_commit with explicit build_state +
commit_state cycle which properly tracks damage. Also schedule a
frame unconditionally every loop iteration to ensure continuous
rendering in nested mode.
Implement wl_drag_begin as a simple internal drag-and-drop state machine
for WINGs-to-WINGs drag operations (color wells, text widgets).
On button press, waits for motion to confirm drag intent, then enters
a drag loop tracking the cursor. On release, finds the view under the
cursor and if it has drag destination procs + matching types, fetches
data from the source and calls performDragOperation on the destination.
This handles same-process DnD without needing wl_data_device protocol.
findMenu() only checked root_menu, switch_menu, and window_menu.
Dock and clip menus were never found, so pointer motion over them
could not highlight entries or activate on release.
Add CHECK_MENU calls for scr->dock->menu, scr->clip_menu, and
scr->dock_pos_menu.
The optimization that skipped pango_layout_set_text when the text
matched the previous layout content used pango_layout_get_text()
which returns an internal pointer. This pointer comparison with
arbitrary input text could read freed memory or trigger heap
corruption in Pango internals when the layout state was stale.
Always call pango_layout_set_text unconditionally. The cost is
negligible (Pango internally short-circuits if text is identical).
Add selection_fetch vtable slot for synchronous selection retrieval.
On Wayland, WMRequestSelection uses this to fetch clipboard/primary
selection data directly (via W_ClipboardFetchFn -> seat pipe read)
and calls the callback immediately. On X11, the async path
(selection_request -> SelectionNotify event) is unchanged.
This makes middle-click paste work in WINGs text widgets on Wayland.
Phase D (WINGs widget X11 elimination) is complete with 7 commits.
The src/ core audit confirms all X11 is already routed through
wm_backend-> dispatch. The entire codebase has zero X11 executing
on the Wayland path.
W_TopLevelOfView returns NULL for views without a topLevel ancestor
(e.g. geometry display widgets parented directly to root). On X11 this
never triggered because expose events only arrived for mapped windows
with proper widget hierarchy. On Wayland, wl_redisplay synthesizes
expose events for any view, exposing the NULL case.
Fix: fall back to the view itself when no topLevel ancestor exists.
The magnifier is X11-backend-specific (screen capture). Instead of a
disguised is_x11 check, the view backend provides the callback directly:
- X11: .magnify_callback = W_ColorPanelMagnify (the magnifier impl)
- Wayland: .magnify_callback = NULL (button does nothing)
The button wiring uses the vtable value as the action callback.
No conditionals, no capability flags, pure vtable dispatch.
Also removes the screen_grab_image vtable slot that was a disguised check.
Converts 60 X11 calls (XCreatePixmap, XFreePixmap, XCopyArea,
XFillRectangle) to render backend vtable dispatch. Remaining 40
calls are all in the magnifier feature (screen capture, inherently
platform-specific) and will be handled separately.
x11_clipboard_fetch now returns wmalloc copy (XFree internally).
Callers use wfree uniformly on both backends. Prevents X11 regression
where XFree was called on wmalloc memory or vice versa.
Adds drag_begin slot to W_ViewBackend. WMDragImageFromView dispatches
through it. X11 backend sets NULL (falls through to existing XDND
code). Wayland backend is a no-op — prevents crash without guards.
Bridges WINGs internal clipboard to the Wayland seat selection so
copy/paste works between compositor-internal dialogs and real
Wayland clients. Store creates a wlr_data_source and sets seat
selection. Fetch reads from foreign selection sources via pipe.
Adds clipboard_store/clipboard_fetch to W_ViewBackend. Replaces
direct XFetchBuffer/XStoreBuffer calls in wtextfield.c and wtext.c
with vtable dispatch. X11 backend wraps Xlib, Wayland backend uses
an internal buffer.
Replaces all no-ops in wview_wl.c with real implementations:
- move: updates pos, triggers parent redisplay
- resize: reallocates pixman buffer, triggers redisplay
- unmap/unmap_subviews: clears mapped flag, triggers parent redisplay
- raise: moves view to end of sibling list (drawn last = on top)
- lower: moves view to front of sibling list (drawn first = on bottom)
- reparent: moves between parent children lists
Hardcoded white/dark bevel looked wrong against colored titlebars.
Derive highlight and shadow colors from the actual titlebar background
color (+33% for highlight, -33% for shadow) to match the titlebar
bevel style.
Window Maker
Ollie
lkn