In Wayland, pop-ups and such are handled by the client, they are constrained within the client's space. I dont think Sway should do anything with those beside drawing them when the client tells us to.

The problem is that there isn't really good way in wayland for an application to indicate that a "toplevel" window is a dialog or popup and should thus be floating instead of tiled. And since the other most popular compositors (gnome and kde) aren't tiling, they don't have much incentive to implement an appropriate protocol.

This is probably firefox creating a new surface instead of a xdg-popup for dialog windows. Sway can't do much about that.

A popup surface is a short-lived, temporary surface. It can be used to
implement for example menus, popovers, tooltips and other similar user
interface concepts.

I'm not sure that make sense for a lot of these. None of the examples given in the original post fit the examples given in this documentation. And one of the main functions of xdg_popup is that you can position it relative to the parent window. Something that isn't really needed for these types of dialogs. And possibly more importantly, these types of dialogs need to be able to be moved and possibly resized by the user. Something that can't be done with xdg_popup. And there is also the matter of user preference, some users prefer things like browser popups (such as an oauth2 confirmation dialog when logging in using oauth2) to be floating, and other prefer it to be tiled.

But maybe there should be another surface role for dialogs? Something that allows you to move and resize like a toplevel window, but has grab capabilities similar to xdg_popup and indicates to the compositor that it has a child relationship to another window (which could be used for example to make sure it is positioned over or near the parent window) and should probably be floating, but tiling compositors can allow the user to change that.

In Wayland, pop-ups and such are handled by the client, they are constrained within the client's space

I think that maybe you are thinking of something different than what @matejdro is describing for "pop ups". These aren't menus or popovers or tooltips, they are persistent dialogs that often allow you to interact with both the new window and the parent window at the same time (well, alternate between them). They definitely shouldn't be constrained to the client's space, because you may want to move them out of the way of the parent window (for example onto a different monitor).

As another specific example, when I log in to something with google SSO, it opens up a browser popup for me to log in to google with and grant permission to the website. In i3, I can have rules similar to @matejdro to target this window and make it floating. But in sway, the best I can do is try and target the title. But that is a moving target, and I often don't know what the title will be ahead of time.

It does make sense for web browser to use subsurfaces in that case instead of popups. The best you can do is try to find a regex that matches the title and set it as floating.

I'll close the issue.

Can you freely resize subsurfaces, move them and even make them non-floating? I'm not familiar with them, but this is the beauty of the way it currently works with i3: popups are essentially another windows, so they are super flexible.

As mentioned by tmccombs above, there are many use cases for needing to move dialogs around (move them to another monitor to keep an eye on them while using the main window)

Can you freely resize subsurfaces, move them and even make them non-floating?

No you cannot. Unless the application implements functionality for moving them around itself. But that won't integrate with the compositor's capabilities for doing so. And there isn't a way to make them non-floating.

Also, in sway at least, a subsurface is constrained by the bounding box of the parent window. Any part of a subsurface that extends beyond that will be clipped.

The best you can do is try to find a regex that matches the title and set it as floating.

This is really not a good solution. First of all, it isn't scalable. Not only do you need to track the titles from various applications and websites, but in the case of websites the titles can change arbitrarily with no warning. Furthermore, in the case of browser windows, the title isn't set until after the window is initially created, which results in a twitchy experience, as the window is initially tiled and then switches to floating once the title is set. And in some cases there may not be a title, or the title may be the same as the parent window (or in the case of the browser another page on the same website).

I do think though, that the proper place to fix this is adding to the xdg-shell specification.