Synchronized Wayland popup moving
Quoting the protocol commit message:
Moving can be done in two ways: implicit and explicit. Implicit popup moving is done by setting a adjustment flag on the positioner used to create it that will cause the compositor to adjust the position as the conditions used to constrain it change. These changes may include, for example, changes in the position of the parent window or the geometry of the work area. To allow the client to update its content in response to the updated position, the client must ack the configure event, optionally with new content. Until the client acks this configure event, the existing positioner will continue to be used. Explicit popup moving is done using a new request on xdg_popup: xdg_popup.move. What it does is change the parameters used for positioning a popup by providing a new xdg_positioner object. This request is coupled with a new event; xdg_popup.moved, sent together with the configure events (xdg_popup.configure and xdg_surface.configure) to notify about the completion of the move request. The move request also takes a token that is later passed via the moved event; this is done so that a client may determine for which move request the compositor has sent configure events. Both these methods by themself are racy regarding inter-surface synchronization. In order to avoid race conditions when applying new states, a new request is also added to xdg_surface: xdg_surface.sync_with_popup. This request is a one-shot request to defer application of the to be committed surface state until the state of the passed popup surface is applied. Lastly, a request to couple a xdg_positioner object with a configure event is added in order for a compositor to pair a popup move request with a pending configure event. This is necessary to, for example, properly constrain a popup given a yet-to-be-applied parent state. An example of when this may be necessary is an interactive resize where both the toplevel position and the relative popup position changes.
For further explanation, for how it's expected to work, see https://lists.freedesktop.org/archives/wayland-devel/2019-July/040758.html
The corresponding GTK merge request: gtk!1017 (merged)
The first part of the merge request could potentially be split up, as it's more of a cleanup.