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 f2db9402b74ad58c4267eb6ec98d2904b6923820
Author: Cedric BAIL <[email protected]>
AuthorDate: Sun Aug 16 11:34:42 2026 -0600
e_comp_object - let the frame lead the buffer during an interactive resize
The clamp to the pixmap in _e_comp_intercept_resize rests on the assumption
that a client cannot be a size its buffer is not. wp_viewporter already had to
break that assumption; an interactive resize breaks it a second way, and this
one has nothing to do with viewports.
While the user drags an edge it is the compositor driving, and a wayland
buffer cannot lead: we send a configure and the client's resized buffer
arrives a commit later, or never. So the clamp rewrote every step of the drag
back to the size the old buffer happened to be, and the window did not follow
the pointer:
PROBE clamp: req=360x430 pixmap=420x390 clamping=1 resizing=1
PROBE clamp: resized to 420x390, EVAS now 100,100 420x390
The half that is felt rather than seen is worse. ec->w/h and ec->client.w/h
are set to the requested size twenty lines above the clamp, so for the whole
drag E's own bookkeeping and the canvas disagreed - and a frame that never
moved still claims the input for where it should have been. That is the shape
this looks like on real hardware: a window whose decoration stays put while
the content moves, and clicks that land where the window used to be.
It also silently disabled the compensating move further down. The resize modes
that pull the top or left edge have to move the origin as the size changes,
and _e_comp_intercept_resize does that itself, from prev_w - cw->w, with
force_move set so the guard in _e_comp_intercept_move lets it through. Clamping
pinned that difference at zero, so the move was a no-op. Note this is why
disabling that guard on its own changes nothing and reads as a dead end: there
are two bugs here and either one alone still fails the test. The guard is
correct and stays.
X clients keep the old behaviour. There the pixmap really does resize with the
window, the buffer is never behind, and the clamp is telling the truth.
Measured: XdgToplevelStableTest and XdgToplevelV6Test
surface_can_be_resized_interactively both go from failing to passing, with the
pointer fix that follows. Full suite 754 -> 756, no other change in the
failure set.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01FtoiXoSKUmZb6Aix6U3GZS
---
src/bin/e_comp_object.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/src/bin/e_comp_object.c b/src/bin/e_comp_object.c
index 4c680350c..7f9449d21 100644
--- a/src/bin/e_comp_object.c
+++ b/src/bin/e_comp_object.c
@@ -1258,6 +1258,32 @@ _e_comp_intercept_resize(void *data, Evas_Object *obj, int w, int h)
if ((cw->ec->content_size.w > 0) && (cw->ec->content_size.h > 0))
pw = cw->ec->content_size.w, ph = cw->ec->content_size.h;
+ /* An interactive resize breaks the same assumption a second way, and this
+ * one has nothing to do with viewports: while the user drags an edge it is
+ * the compositor driving, and a wayland buffer cannot lead. We send a
+ * configure and the client's resized buffer arrives a commit later, or
+ * never, if it decides not to. Clamping to the buffer holds the frame at
+ * the old size for the whole drag, so the window does not follow the
+ * pointer - and because ec->w/h and ec->client.w/h were set to the
+ * requested size a few lines above, E's own bookkeeping and the canvas
+ * disagree for as long as the drag lasts. A frame that never moved still
+ * claims the input for where it should have been, which is the half of
+ * this that is felt rather than seen.
+ *
+ * It also silently disables the compensating move below: for the resize
+ * modes that pull the top or left edge, that move is derived from
+ * prev_w - cw->w, and clamping keeps that difference at zero.
+ *
+ * So let the frame lead and the buffer catch up, which is what dragging a
+ * window edge looks like everywhere else. The image is scaled to the frame
+ * for the frame or two until the client commits.
+ *
+ * X clients keep the old behaviour: there the pixmap really does resize
+ * with the window, so the buffer is never behind and the clamp is telling
+ * the truth. */
+ if (e_client_util_resizing_get(cw->ec) && (!e_client_has_xwindow(cw->ec)))
+ pw = w - fw, ph = h - fh;
+
/* check shading and clamp to pixmap size for regular clients */
if ((!cw->ec->shading) && (!cw->ec->shaded) && (!cw->ec->input_only) && (!cw->ec->override) &&
(((w - fw != pw) || (h - fh != ph))))
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
