4 ms·

Can anyone explain succinctly why basic window management and pointer warping is absent on Wayland, what it would take to fix, and how to get involved fixing it

• arghwhat 1y ago
  The historic reason is that all inputs and window manager state outside your very own window is kept secret, and "stealing" input strictly disallowed. The idea is to avoid clickjacking, eavesdropping, phishing-esque windows, you name it, all which only works when an application has freedom to find other windows, place itself and steal focus and input. Even just stealing a cursor at a bad time might lead an in-progress password input to end up somewhere unintended. It was a good intention, and it's hard to figure out where to draw the line between convenience and capability and secure design. It's absolutely impossible to ask, as everyone will demand everything, claiming even the smallest feature is the foundation of all modern computing. Some of these things are now coming in ways that still aim to keep explicit behavior and decent control, but enable the needed usecases. Cursor warp, session restoration, picture-in-picture, etc.
  • cosmic_cheese 1y ago
    The balance doesn’t necessarily require that much thought or deliberation. It could be as simple as putting things like cursor control behind a permission dialog, with it being mandatory to provide a reason why the capability is needed to present in the dialog to help users make an informed decision.
    • jeroenhd 1y ago
      Web browsers tried that. Then spam sites started saying "press allow to prove you're not a robot". Android showed a whole list of permissions for years whenever you installed an app. Nobody ever read them, phones were full of malware, and Google started nuking APIs and replacing pre-install permission prompts with real-time permission prompts. If letting the application ask nicely is a good enough security measure, then you never needed to ask in the first place. When a user wants to use an application (or, what they think an application does), and the application just says "for the app to work" when the OS queries it for a reason why it needs permissions, the user is going to click permit every time. From a practical security standpoint, the application could just as easily say "I'm going to take control of your mouse OK/cancel". Which is what happens on X11, except applications just take control of your mouse whether you want to or not.
      • cosmic_cheese 1y ago
        There’s some crucial differences here, though. The web is a different beast because people will visit sites on a whim, plus there’s things like redirects to factor in. Friction for visiting sites is very low, which makes the spam problem much worse. Users’ desktops are a very different environment — nearly all programs that are installed are there because the user explicitly willed it. Apps can’t install themselves and users install apps at a much lower rate than they visit sites, and so the only time there’s a “spam” effect is when setting up a new machine (which could be ameliorated by account migration tools copying permissions). Furthermore, if apps start acting abusive there’s a good chance that users will remove them and seek replacements, and so it’s in apps’ best interest to not do that. As for Android, that’s simply a bad permissions model. The iOS/macOS model in which prompts are shown when the user tries to use an associated feature is much better and appropriately triggers mental red flags when incongruent permission requests appear. It’s never going to be perfect, but third party devs have repeatedly proven that full access to everything all the time is not a model that works for anybody but power users and above.
      • queenkjuul 1y ago
        The permissions setup seems to work fine on macOS though. I can grant an application permission to view and manage other windows. Doesn't flatpak have user configurable app permissions as well? I don't see how all-or-nothing is better than letting the admin whitelist what they need and blacklist that they don't
    • arghwhat 1y ago
      It's actually a lot more difficult than that. Working with existing applications as is requires a ditect mapping, and any restrictions or asynchronous prompts would break any existing assumptions in platform agnostic code, so it wouldn't solve things completely. If you make something possible to do something with a permission or configuration, app developers just tell users to accept or configure to not ask, and then we're worse off than if there was no permission at all: the security is bypassed and only the inconvenience remains. It takes a surprising amount of thought and work to do this in any meaningful way, and it cannot be done in a way that isn't somewhat disruptive.
      • cosmic_cheese 1y ago
        It’s a bit crude, but macOS handled the asynchronous prompt problem by suspending the process trying to access something it hasn’t been given permission to use until the user has acted.
  • duped 1y ago
    > The historic reason is that all inputs and window manager state outside your very own window is kept secret, and "stealing" input strictly disallowed. For multi-window applications you're not inside "your own window", you own many windows. Are apps not allowed to get and set properties of windows they spawn under Wayland? I haven't worked on desktop UI in years, but that's very surprising to me if true.
    • simcop2387 1y ago
      > For multi-window applications you're not inside "your own window", you own many windows. Are apps not allowed to get and set properties of windows they spawn under Wayland? Depends on what you're calling properties of the window, wayland does of course have a number of things like that but not all of them are the same as X11 used to be. I don't believe it's got a way to get the position of your own window, and does not have a way to set the position at all since that's considered a property of the compositor's handle on the surface IIRC (not exactly the same as the window, since the compositor can be putting decorations on the surface like the title bar, controls, etc.). A lot of it is consequences of moving some security fences around as other commenters have mentioned, because over the decades a lot of applications (not necessarily on linux or X11, but it has happened there still) have used those other barrier's leakage to do nefarious things like steal passwords, pop up ads on top of what you're doing, etc. I would definitely support an argument that they swung the pendulum further towards "secure by default, even at the expense of what people need" but I'm actually happy they did, because it's quite a bit easier to add the functionality in after you've got something that's secure, rather than design a new barrier that breaks existing things after the fact.
      • arghwhat 1y ago
        > Depends on what you're calling properties of the window, wayland does of course have a number of things like that but not all of them are the same as X11 used to be. Well, technically Wayland has no such thing as properties. It only has requests and events on objects, and no protocol behave like an arbitrary key value store the same way X11 atoms do. You can't ask Wayland how big your window is or should be for example, you decide how big it is right now when you submit a graphics buffer in a requests, and the Wayland server will tell you in an event if it would like it to be a different size (say, because someone dragged a server side decoration or because the window became fullscreen). A key difference between Wayland and X11 is that Wayland is very explicit in how functionality is defined and added.
  • josephcsible 1y ago
    > It's absolutely impossible to ask, as everyone will demand everything, claiming even the smallest feature is the foundation of all modern computing. The problem is they want it both ways. If they're not willing to support literally every use case that X supports, then Wayland should merely exist alongside X, like Emacs alongside vi, rather than removing X from so many distros and desktop environments.
    • arghwhat 1y ago
      1. Display servers are highly security sensitive and cannot be shipped in good faith unless they are well maintained. The only high-profile X server still around, xorg, is entirely unmaintained outside its Xwayland support, and no one is willing to step up. Volunteers own their own life and time within it and have no obligation to pick up arbitrary projects and tasks. The primary way to make people do something no one volunteers for is to hire them and pay them for it, but no one is interested in that either. (One person did famously, and very vocally, volunteer and do a lot of work, but unfortunately almost all of it had to be reverted recently after it was found to break everything.) 2. Wayland and X does, for and enduser, coexist through Xwayland. You just no longer run a "native" X11 display server that controls hardware directly. Most Wayland servers afford Xwayland some slight additional controls for just the X11 windows, allowing applications to work seamlessly, so everything is fine. And no, the "most" qualifier is no issue at all as applications relying on such control also only worked with some X11 window managers.
• phendrenad2 1y ago
  I couldn't find an explanation for the need for cursor warping support, someone in Lobsters said it might be so the "cursor could move with a moving object" which doesn't immediately resonate with me, as a frequent CAD, even LiCAD, user. Hmm. Chances are "cursor warping" here refers to how "cursor locking" is typically done in win32 (every time the cursor moves, record the distance and reset it to the original location). Ironically, in the announcement about cursor warping being released, they say that it's not reliable for that use case, but that a "cursor lock" was already implemented. So it would be funny if KiCAD was just too stuck in Windows mentality to realize that what they needed was already supported.