Skip to content

RFC: text_input_v3 Handling of invalid state changes

Dorota Czaplejewicz (Purism) requested to merge dcz_purism/wayland-protocols:enable into wip/text-input-next

While working on https://gitlab.gnome.org/GNOME/gtk/merge_requests/1354 I have noticed that there's a corner case where the client would be required to accept compositor's changes even if it didn't request a text input. This would directly lead to the compositor sending changes with zero information about what it actually changes. The situation would occur after every enter event.

I decided to solve it by changing how serial numbers work, and repurposing the serial "0" to mean "the compositor has no information about text input", making it easy to filter.

The RFC is in the title because I'm not sure how this should work with integers overflowing. There's an implicit assumption that the serial will simply overflow back to zero, but this assumption would cause trouble now. Should serial be explicitly defined to overflow back to 1? Or maybe there should be a more textual explanation of how to handle the uninformed events?

The commit message for !16 (4b127593) explains the reasoning in detail.

Edited by Dorota Czaplejewicz (Purism)

Merge request reports