Saving the position of windows is, generally speaking, wrong at every level, unless you’re literally restoring a session from a shutdown—and the monitor geometry is identical to the previous session. The only component capable of making that decision is the display server, not the application or the toolkit. Saving the size, and setting it up as the default size (which is overridable by the display server/compositor) is entirely possible on any windowing system; since it’s an application functionality, applications can decide whether or not to do it.
As for centering windows on the screen: again, the only component with enough privileges to determine where the window should be places is the display server, because it’s the only component that knows where all the windows and all the monitors are. For that, you may want to have some form of identification for windows that should be centered on a display, like a window type or some form of “tag”. It should be discussed with the GNOME Shell developers, or with the wayland-protocols maintainers and consumers—i.e. every other Wayland compositor.
That happens because applications try to restore a (0, 0) position, which is broken. The compositor should try to position windows freely, to satisfy the constraints in the window size and monitor geometry; if applications keep asking to set the position then things will fail.
I don’t understand why this would be the case?
If setting position doesn’t work anymore then it should simply be a no-op, no?
Wayland broke this, not the applications.
Whether we agree or not that this is the right thing to do is really irrelevant. It is what is.
But blaming applications seems misplaced to me. Toolkits have all the information they need to decide whether moving the window as requested will actually work or not. So they should either drop the functions related to positioning windows entirely or make it a no-op on Wayland since X11 will still be around for a long, long time and it works just fine there.
At the end of the day it hasn’t stopped me from using Wayland, it’s just another paper cut.
Setting the position to (0, 0) won’t do anything, really; but compositors typically will try to put windows where it makes more sense in terms of empty room on the current monitor. Compositors were really doing this even before Wayland, if you didn’t try to move the window yourself when mapping it.
If all your windows end up all at (0, 0) under GNOME Shell, then you have to talk to the GNOME Shell developers; it has nothing to do with Wayland.
In the same way that putting a car alarm broke the expectation of the people trying to steal your car, yes.
I don’t blame pieces of software, that would be pointless. I do blame windowing system developers, because they never should have expose the ability to position top level windows directly.
The security issue is being able to access the entirety of the coordinate space of any display; that would allow rogue windows to position themselves on top of existing user controls—like a text entry, or another window—and interpose themselves to other legitimate applications.
You start by saying: “applications should each live in its own isolated bubble, so there is no chance for a bug to lead to an insecure state, with potentially user hostile applications having access to things outside of that bubble”, and you end up eliminating anything that affects global/shared state, unless it comes with the ability to have a privileged component mediate the request—possibly with user consent.
Just to be clear on my personal position (pun unintended) on the specific topic of window positioning:
While I am a bit sad to see the deprecation of the ability for apps to set their desired position, I however understand the reasoning (mainly “it’s the WM’s job to find out the appropriate place to put them, the app can’t guess”); until now I didn’t think there could be security considerations as well! In any case, I have internalized/accepted that loss.
What I am advocating for however (in my comment on Mutter’s “window centering” issue), is better window fallback positioning; in other words, I say “(0, 0)” is a bad fallback for “whenever the window manager can’t figure out a nice way to position the window without overlapping”. The fallback should be “center the window” instead; it would make much more sense and look less “broken”. As I explain in my comment over there, Mutter under Xorg already does this under some circumstances (ex: when spawning on top of a maximized window under Xorg), it just needs to also do that in Wayland, and ideally to extend that logic to some more fallback cases as well.