wlr_seat_pointer_notify_button delivers to the surface that currently has pointer focus. If the last wl_update_pointer_focus call was during a motion event that targeted a different area (e.g., titlebar), the XWayland client surface might not have focus when the user clicks on its content area. Added wl_update_pointer_focus call before wlr_seat_pointer_notify_button in handle_pointer_button to ensure pointer focus is always current.
WMEButton and WMEMotion are separate structs in the WMEvent union with different field layouts — u.motion.x is at a different memory offset than u.button.x. The WME_BUTTON_PRESS handler in wslider.c was calling valueForMousePoint(sPtr, event->u.motion.x, event->u.motion.y) which reads uninitialized memory on Wayland (memset zero = 0). On X11 this happened to work because the X11 event translator writes to both union members. Fix: changed all event->u.motion.x/y references to event->u.button.x/y in the WME_BUTTON_PRESS case.
W_FindViewAtPoint finds the correct child view (slider, checkbox, etc.) but does not adjust event coordinates. The WMEvent x/y were set relative to the top-level WINGs view (fb->x, fb->y origin), while widget event handlers (getSliderPart, valueForMousePoint, etc.) expect coordinates relative to the widget view itself. Fixed by computing the accumulated offset from the target view up to the toplevel and subtracting it from the event coordinates. Applied to both handle_pointer_button and handle_pointer_motion.
handle_pointer_motion enqueued WME_MOTION events with target=NULL. On button press, handle_pointer_button correctly resolves the WINGs child view (slider) via W_FindViewAtPoint and sets _view_target, so the slider receives the press and sets dragging=1. But subsequent motion events had NULL target, so WMHandleEvent routed them to the top-level view instead of the slider view — the slider never received WME_MOTION during drag. Fix: add W_FindViewAtPoint resolution in handle_pointer_motion, matching the button press logic.
Window Maker
Ollie