Bug 1: Clicks on menu items did not select the correct item.
The WME_BUTTON_PRESS handler always called popUpMenu() which re-mapped
the already-open menu and reset highlightedItem to selectedItemIndex,
ignoring the click position. Since no motion event follows a
click-without-drag, the highlight was never corrected.
Fix: distinguish menuView vs main button events via event->window.
For menuView clicks, compute highlightedItem from click.y directly
without re-opening the menu.
Bug 2: Second popup open showed a blank gray box.
wl_unmap disabled the compositor scene node via W_ViewSceneNodeSetEnabledFn
but wl_map never re-enabled it. On re-map, the buffer was committed
to the wl_surface but the scene node stayed disabled.
Fix: re-enable scene node in wl_map before redisplay.
Reorder popUpMenu to:
1. Resize menuView before map (correct backing dimensions)
2. W_MapView first (wl_map calls wl_redisplay which fills background
and dispatches WME_EXPOSE — the old redisplay() before map was a
no-op on Wayland because wl_redisplay returns early when !mapped)
3. Copy makeMenuPixmap() output into menuView->window backing as a
safety net, ensuring the buffer has complete menu content
independent of expose-timing correctness
4. paintMenuEntry for initial highlighted item
This ensures the first visible popup buffer has all menu items
rendered regardless of the order in which the Wayland configure
and commit events arrive.
Three related fixes for WINGs popup menus on Wayland:
1. wl_client_toplevel_resize: update pending_w/h after resize
(wclient_wl.c:545-546). Without this, the configure handler sees
stale pending dimensions and creates a wrong-sized buffer,
discarding the one containing the menu text.
2. Export wl_redisplay_depth (wview_wl.c:288) so render and font
backends can detect when they are called from within a full
redisplay cycle vs. from an event handler.
3. Add cascade+commit to render_wl_fill_rect (wrender_wl.c:162-183)
and wl_draw_string (wfont_wl.c:183-208) when not inside a
redisplay cycle. This makes motion-driven highlight changes
(text color, background fill) immediately visible by compositing
up the view tree and committing the toplevel wl_surface.
When a window is shaded (rolled up to titlebar only), the client surface
is hidden but view_surface_at would still return it for points over the
frame decorations. This caused two symptoms:
1. Pointer focus stayed on the client surface, showing I-beam cursor
instead of default arrow over the titlebar.
2. Button events routed to the client surface instead of titlebar,
preventing double-click-to-unshade from working.
Fix: after matching a toplevel view via scene graph, check whether the
associated WWindow has flags.shaded set and skip it if so.
When wl_window_resize frees the old pixman image and creates a new one,
it must call W_RegisterBacking to update the backing store. Otherwise
W_GetViewBacking returns the freed old image pointer, causing a crash
when WMDrawString (via wl_font_resolve_drawable) tries to draw into
the stale backing. This manifests on workspace name badge display
in direct render mode.
When handle_pointer_button finds a client surface at the pointer (_surf && _tv),
it searches frame_list for overlapping WINGs frame_bufs. Previously it used
any WINGs fb found, including stale entries with bogus IDs (e.g. 0x1).
Now it validates the WINGs fb via context_find() before using it as the
event window. If validation fails, the event routes to _tv->id.
The seat keyboard may be the XWayland virtual keyboard when a client
has focus, which carries no modifier state. Reading
seat->keyboard_state.keyboard->modifiers.depressed for button events
then yields 0 even when the user holds Alt, so frameMouseDown's
MOD_MASK check always fails and Alt+drag never starts.
Add current_mods to wl_compositor_state. Update it from the real
keyboard in handle_keyboard_modifiers, which fires on every modifier
change from the physical device regardless of seat focus. Use
wl_state.current_mods in handle_pointer_button to populate
u.button.state and to gate the client-forwarding suppression.
The pointer_grab call for Alt+drag (move/resize via MOD_MASK on client
surface) was passing owner_events=0. wl_pointer_grab only sets
grab_type=3 and clears seat pointer focus when owner_events is True;
with 0 the grab returned success but left no grab state, so motion
events continued flowing to the client instead of the WM drag loop.
Pass 1 (True) to match the calls in resizebarMouseDown and
titlebarMouseDown, which work correctly.
When the WM modifier key (Alt by default, configurable via ModifierKey)
is held during a button press over a client surface, do not forward the
event to the client via wlr_seat_pointer_notify_button. The event has
already been enqueued for the WM policy layer via W_WL_EnqueueEvent;
frameMouseDown will call wMouseMoveWindow (LMB) or wMouseResizeWindow
(RMB) as appropriate. Without this suppression the client application
receives the Alt+click and may act on it instead of the WM.
Three related fixes for the Wayland backend:
wl_handlers.c: populate u.button.state with keyboard modifiers
Button events were built with state=0 after memset, so all modifier-
dependent logic in window.c (resizebarMouseDown, frameMouseDown,
titlebarMouseDown) received no modifier information. Read the current
depressed modifier mask from the seat keyboard and copy it directly --
wlroots WLR_MODIFIER_* bits match the WM_MOD_* layout exactly.
wl_framebuf.c: fix frame_buf_hit to resolve child sub-windows
frame_buf_at() uses wlr_scene_node_at() which skips frame_buf children
whose scene_buf has no committed buffer (resizebar, titlebar pixels are
composited into the parent frame buffer). The hit always resolved to
the top-level frame, so events were dispatched to frameMouseDown instead
of resizebarMouseDown, and resize never started. After frame_buf_at
returns a top-level frame, do a coordinate-based child search and return
the smallest (most specific) child that contains the pointer -- the same
strategy frame_buf_button_at uses for buttons.
wl_events.c: fix wl_coords_translate to return frame-relative coords
The stub was a pass-through returning root-relative coordinates unchanged.
wMouseResizeWindow calls coords_translate(root, frame->core->window, ...)
to get frame-relative click coordinates for getResizeDirection(). Look up
the dst window in the frame_buf list and subtract its absolute position.
Three interrelated bugs caused clicks to land in the wrong place when
the compositor spanned multiple outputs (e.g. two 1920x1080 monitors
side by side in nested Wayland mode):
1. real_pointer_update_global() added lo->x to coordinates that were
already in layout space from wlr_cursor_absolute_to_layout_coords,
double-counting the output offset. It also omitted lo->y entirely,
breaking vertical monitor layouts. Fix: read position from
wlr_cursor->x/y which is always authoritative layout-space.
2. real_pointer_handle_motion() accumulated ev->delta into local_x/y
then set pointer_x/y, after which handle_pointer_motion() added
the same delta again -- doubling every relative motion. Fix: let
handle_pointer_motion() be the sole authority; use wlr_cursor_move()
which respects output layout geometry.
3. Pointer devices from nested Wayland outputs (WL-1, WL-2) were never
registered with wlr_cursor via wlr_cursor_attach_input_device() or
mapped to their output via wlr_cursor_map_input_to_output(). Without
this mapping, wlr_cursor_absolute_to_layout_coords treated the 0..1
range as spanning the entire layout (0..3840) instead of the
device's specific output (e.g. 1920..3840 for WL-2). A previous
workaround disabled absolute motion entirely for nested multi-output,
which left only relative deltas that had no concept of which host
window the mouse was in. Fix: register devices with wlr_cursor and
map them to their outputs; remove the early-return.
All pointer paths now follow the same pattern: mutate position via
wlr_cursor_move()/wlr_cursor_warp(), then read back cursor->x/y into
wl_state.pointer_x/y. Manual bounding-box clamping is retained only
for the no-cursor fallback (headless/test mode).
lkn
Window Maker