This is an automated email from the git hooks/post-receive script.
git pushed a commit to branch wl/browser-all
in repository enlightenment.
View the commit online.
commit 8813a33828bc9f24472f8c7a34334f83f1618095
Author: Cedric BAIL <[email protected]>
AuthorDate: Tue Aug 11 14:30:33 2026 -0600
tests - route synthesised pointer motion through the manager too
E has two input halves: manager-level handlers are fed ecore events,
clients are fed evas callbacks on their frame object. A real session
feeds both, ecore first. wl_test fed only the second, so anything E
hangs off the first was unreachable under test.
Pointer constraints and relative-pointer are both on that side, and
_e_comp_cb_mouse_move() in e_comp_canvas.c is the only caller of
e_comp_wl_extension_pointer_constraints_update() in the tree. With the
manager half missing, a locked pointer never locked, a confined one never
confined, and relative motion was never reported - so a protocol that is
implemented and works read from the outside as one nobody had written.
That is worth being precise about: this is a hole in the harness, not a
hole in the compositor, and it made ten wlcs failures look like missing
features.
Same gap 4fbbe3d07 closed for buttons, and the comment it left in this
same function already said as much - "not the whole story for buttons".
Motion was never done. So: the same remedy, calling what the manager
would have called, in the order it would have called it, under the same
guards. When the constraint swallows the motion it has warped the pointer
somewhere of its own choosing, and the canvas must not then be told the
pointer went where the test asked; the real handler answers
ECORE_CALLBACK_CANCEL there for that reason.
Still missing, and not fixed here: the real handler ends by calling
e_comp_wl_grab_client_mouse_move(), so motion during a popup grab is
routed for buttons but not for motion. Nothing measures it today.
wlcs: 701 passed -> 702, no regressions. locked_pointer_does_not_move now
passes, which says the enforcement path works once a constraint is
active. The remaining ten need a constraint to activate with the pointer
standing still, which E does not do - see
E20-POINTER-CONSTRAINTS-HANDOVER.md.
---
src/modules/wl_test/e_mod_main.c | 36 +++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/src/modules/wl_test/e_mod_main.c b/src/modules/wl_test/e_mod_main.c
index 792b72e88..5bb9bb54a 100644
--- a/src/modules/wl_test/e_mod_main.c
+++ b/src/modules/wl_test/e_mod_main.c
@@ -132,10 +132,44 @@ static int _pointer_x = 0, _pointer_y = 0;
static void
_wl_test_cb_pointer_warp(struct wl_client *client EINA_UNUSED, struct wl_resource *resource EINA_UNUSED, int32_t x, int32_t y)
{
+ E_Client *focused;
+
/* Feeding evas delivers to the client: E's wayland pointer handlers are
* evas callbacks on the client's frame object, so a synthesised evas event
* reaches the client exactly as a real one would. No uinput, no libinput,
- * no seat. It is not the whole story for buttons - see below. */
+ * no seat. It is not the whole story for buttons - see below - and it is
+ * not the whole story for motion either.
+ *
+ * A real session hands motion to ecore first, and E hangs two protocols off
+ * that half in _e_comp_cb_mouse_move() (e_comp_canvas.c): relative-pointer
+ * and pointer-constraints. Neither is reachable from the canvas, so with
+ * only the evas feed a locked pointer never locks, a confined one never
+ * confines, and relative motion is never reported - which reads from the
+ * outside exactly like a protocol nobody implemented. It is implemented;
+ * the harness was talking to the wrong half of E.
+ *
+ * Same shape as the button case below, so the same remedy: call what the
+ * manager would have called, in the order it would have called it. */
+ focused = e_client_focused_get();
+ if (focused && (!e_comp_util_mouse_grabbed()) &&
+ ((x != _pointer_x) || (y != _pointer_y)))
+ {
+ if ((!e_comp->screen) || (!e_comp->screen->relative_motion))
+ e_comp_wl_extension_relative_motion_event(ecore_time_unix_get() * 1000ULL,
+ x - _pointer_x, y - _pointer_y,
+ 0, 0);
+
+ /* A constraint that swallows the motion has already warped the pointer
+ * somewhere of its own choosing, and the canvas must not then be told
+ * it went where the test asked. The real handler answers
+ * ECORE_CALLBACK_CANCEL at this point for the same reason. */
+ if (e_comp_wl_extension_pointer_constraints_update(focused, x, y))
+ {
+ evas_pointer_canvas_xy_get(e_comp->evas, &_pointer_x, &_pointer_y);
+ return;
+ }
+ }
+
_pointer_x = x;
_pointer_y = y;
evas_event_feed_mouse_move(e_comp->evas, x, y, 0, NULL);
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
