This is an automated email from the git hooks/post-receive script.
git pushed a commit to branch wl/real-browser
in repository enlightenment.
View the commit online.
commit 2f46760aa6ad47a31e7a5ad5fc815e9865d1f64c
Author: Cedric BAIL <[email protected]>
AuthorDate: Sun Aug 16 22:24:12 2026 -0600
e_comp_wl - a configure sent while applying a commit countermands the last one
Firefox came up at 500x120 against a nested E. Maximising a window set the
maximized state and left the window exactly the size it was. Same cause.
The size in a configure is an instruction, and configures are not answered
instantly, so E must not issue one while its own geometry is mid-flight. It
did, from two places, both reached while a client commit was being applied:
* _e_comp_wl_evas_cb_state_update. The default maximize policy has type
E_MAXIMIZE_FULLSCREEN, and e_client_maximize calls the "fullscreen" smart
callback for that type, so a plain maximise lands here. The maximise is
applied during the commit that acked it, and at that point ec is still the
size the client had before - the resize is the client's to make, from the
configure maximize_pre already sent it. Imposing ec's size here sends a
second configure countermanding the first.
* _e_comp_wl_evas_cb_resize, by the same route: the commit path resizes ec to
the buffer the client just sent, which lands in the resize callback, which
echoes that size straight back as an instruction.
Traced with the serials, which is the only way this is legible:
send_configure serial=4 320x240 max=0
send_configure serial=5 1024x768 max=1 <- the maximise, correct
ack 4 -> commit 320x240
ack 5 -> commit, set.max=1
state_update: ec=320x240, in_commit=1
send_configure serial=6 320x240 max=1 <- countermands serial 5
ack 6 -> commit 320x240
The client obeys both and the later one wins, so the window ends up flagged
maximized_h | maximized_v at its original size. A browser does exactly the
same, which is why Firefox opened in a corner: every configure E sent it was
answered by another one putting it back.
in_commit is the guard maximize_pre already uses, a few functions up, for the
same reason - E's geometry is not settled while a commit is being applied. Both
sites now use it. Nothing is lost by not sending: the configure carrying the
new size and the new state has already gone out, and the client answers that
one.
Measured: with the fix, Firefox 153 against a nested E on wl_x11 fills the
1280x1024 screen instead of sitting at 500x120.
test_wl_client_action asserted the maximise round trip and was marked xfail
when it was written; it passes now and the marker is gone. wl-globals, all nine
protocol tests and e_wlcs_driver pass.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
---
src/bin/e_comp_wl.c | 32 +++++++++++++++++++++++++++++++-
src/tests/wayland/meson.build | 2 +-
src/tests/wayland/test_client_action.c | 32 +++++++-------------------------
3 files changed, 39 insertions(+), 27 deletions(-)
diff --git a/src/bin/e_comp_wl.c b/src/bin/e_comp_wl.c
index 28e96a6ff..8bcde9431 100644
--- a/src/bin/e_comp_wl.c
+++ b/src/bin/e_comp_wl.c
@@ -1125,6 +1125,24 @@ _e_comp_wl_evas_cb_resize(void *data, Evas_Object *obj EINA_UNUSED, void *event
if ((ec->shading) || (ec->shaded)) return;
if (!ec->comp_data->shell.configure_send) return;
if (ec->comp_data->maximizing) return;
+
+ /* A resize that *is* the client's own commit being applied must not be
+ * answered with a configure. The size in a configure is an instruction, and
+ * an instruction echoing the size the client just committed pins it there -
+ * which is a problem precisely when the client is behind.
+ *
+ * Configures are not answered instantly. Maximise looked like this: E sends
+ * "be 1024x768"; the commit answering the *previous* configure, still
+ * 320x240, arrives; E applies it, lands here, and sends "be 320x240",
+ * countermanding its own maximise. The client obeys both, last one wins,
+ * and the window ends up flagged maximized at its original size. A browser
+ * does the same thing and comes up in a corner - this is very likely why
+ * Firefox opened at 500x120 against a nested E.
+ *
+ * in_commit is the same guard maximize_pre already uses two functions up,
+ * and for the same reason. */
+ if (ec->comp_data->in_commit) return;
+
if (e_client_util_resizing_get(ec) && e_comp_wl->resize.edges)
{
int x, y;
@@ -1183,7 +1201,19 @@ _e_comp_wl_evas_cb_state_update(void *data, Evas_Object *obj EINA_UNUSED, void *
if (e_object_is_del(E_OBJECT(ec))) return;
- /* check for wayland pixmap */
+ /* Same rule as the resize callback above: while a commit is being applied
+ * E's own geometry is mid-flight, so it must not issue size instructions.
+ *
+ * This fires from e_client_maximize, which reaches here because the default
+ * maximize policy has type E_MAXIMIZE_FULLSCREEN and e_client_maximize
+ * calls the "fullscreen" callback for that type. The maximise is applied
+ * during the commit that acked it, and at that point ec is still the size
+ * the client had before - the resize is the client's to make, from the
+ * configure maximize_pre already sent it. Imposing ec's size here sends a
+ * second configure countermanding the first: "you are maximized, be
+ * 320x240". The client obeys the later one and ends up flagged maximized at
+ * its original size. */
+ if (ec->comp_data->in_commit) return;
if (ec->comp_data->shell.configure_send)
_e_comp_wl_configure_send(ec, 0, EINA_TRUE);
diff --git a/src/tests/wayland/meson.build b/src/tests/wayland/meson.build
index 583a115fc..511bd7bfd 100644
--- a/src/tests/wayland/meson.build
+++ b/src/tests/wayland/meson.build
@@ -68,7 +68,7 @@ wl_protocol_tests = [
['activation', 'test_activation.c'],
['buffer-scale', 'test_buffer_scale.c'],
['client-list', 'test_client_list.c'],
- ['client-action', 'test_client_action.c', 'xfail'],
+ ['client-action', 'test_client_action.c'],
]
# Shared plumbing: registry binding, toplevel construction, enumeration and a
diff --git a/src/tests/wayland/test_client_action.c b/src/tests/wayland/test_client_action.c
index 975f8eef4..eddeaae83 100644
--- a/src/tests/wayland/test_client_action.c
+++ b/src/tests/wayland/test_client_action.c
@@ -12,33 +12,15 @@
* it back exactly where it was means E kept the pre-maximise geometry and
* restored it, which is the part a client notices when it is wrong.
*
- * EXPECTED TO FAIL - marked xfail in meson.build. The behaviour asserted here
- * is the correct one; E does not have it yet.
+ * The configure sequence this test drove out, before the compositor fix that
+ * came with it:
*
- * E maximises the *state* and then takes the *size* back. The configures this
- * test's toplevel receives, in order:
+ * 0x0 0x0 320x240 1024x768 320x240
*
- * 0x0 the initial "you choose"
- * 0x0
- * 320x240 our own size, acked
- * 1024x768 the maximise - the whole zone, which is right
- * 320x240 and immediately back to where it started
- *
- * so the window ends up reporting maximized_h | maximized_v at its original
- * 320x240. _e_comp_wl_evas_cb_maximize_pre (e_comp_wl.c) sends the maximised
- * size and then restores ec->w/h, because a compositor may not resize a
- * Wayland client by fiat and the client's own commit is supposed to drive the
- * resize. What is missing is the other half: when that commit arrives at
- * 1024x768, E compares it against ec->w/h - still 320x240 - and corrects the
- * client back down. Nothing remembers that E asked for the larger size.
- *
- * A real client obeys, which is very likely why Firefox came up at 500x120 in
- * the browser probe rather than at anything sensible.
- *
- * Fixing it means tracking the size of the configure E has sent and not yet
- * seen acked, which is ordinary xdg-shell bookkeeping and a real piece of
- * work. When it lands, this test goes green and meson reports the unexpected
- * pass - which is the signal to delete the xfail marker.
+ * 1024x768 is the zone and is right; the 320x240 after it countermanded the
+ * maximise. It came from _e_comp_wl_evas_cb_state_update, which fired while
+ * the maximise was being applied during a commit - so E's own geometry was
+ * still the pre-maximise size - and imposed it. See the note there.
*/
#include <stdio.h>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
