Support for window placement in Wayland

[michaelwasserman]

See this excerpt regarding Wayland from our API's recently authored Design Risks document.

Wayland is a replacement for Linux’s X window service. Gnome/Mutter and KDE/Plasma desktops plan to use it. Chrome OS will transition to Ozone/Wayland (see Lacros) with some protocol extensions and additional Ash-integrations via a Mojo side channel. Chrome Browser is also building support to run as an Ozone/Wayland client in Linux desktop environments.

Wayland was explicitly designed to prohibit clients from introspecting or programmatically changing their global window coordinates. “Wayland doesn't provide clients with global screen coordinates.”

It is a design decision in Wayland/desktop to not expose absolute window positions to clients at all. This means that you simply cannot know where a top-level window is precisely, you can only know which outputs it overlaps with. - pq

Brief testing of Gnome/Wayland on Debian rodete, and Chrome OS Wayland dogfood indicate that pre-existing and proposed window placement features are quite broken:

• ❌ Web Platform: window.screenX|Y are always 0
• ❌ Web Platform: window.open's left=x,top=y features are always disregarded
  • ❌ (even for legacy same-screen placement values)
  • ✅ width=w,height=h are respected
• ❌ Web Platform: window.moveTo(x, y) and window.moveBy(dx, dy) are disregarded
  • ❓ (likely ✅) window.resizeTo|By()
• ❌ Web Platform: proposed target screen for element.requestFullscreen() is disregarded
• ✅ Web Platform: screen.availTop|Left|Width|Height work (% per-display scaling issues)
  • ❓ (likely ✅) proposed screen.left|top
• ❓ (likely ❌) Chrome App: chrome.windows.create() createData left|top, onBoundsChanged
• ❓ (likely ❌) Chrome App: (deprecated) chrome.app.window
  • ❓ (likely ❌) outerBounds, onBoundsChanged, etc.
  • ❓ (likely ❌) create() CreateWindowOptions bounds

Wayland offers these tools to client applications:

• wl_surface:event:enter|leave - Know what displays a window is shown on
• wl_output:event:geometry - Know the geometry of (connected displays?)
  • We’re already using this screen information for window.getScreens()
  • “This object is published as global during start up, or when a monitor is hotplugged”
• wl_shell_surface:request:set_fullscreen - Enter fullscreen on a specific display
  • We should implement element.requestFullscreen({screen:s}) with this
  • See also zwp_fullscreen_shell_v1 - It's marked as unstable but implemented broadly.
• wl_shell_surface:request:set_maximized - Enter maximized state (on a specific display?)
• xdg_surface:request:set_window_geometry - set relative geometry of child windows
• xdg_positioner:enum:constraint_adjustment - set surface positioning guidance

Per crbug.com/1261321, Chrome OS plans to support window's positioning in screen/display coordinates. This will likely be via protocol extensions, to avoid message ordering issues between Wayland protocol messages and mojo.

Potential Wayland Protocol Extensions (hand waving by @michaelwasserman):

• xdg_surface:event:geometry - event fired when window geometry initializes or changes.
• xdg_surface:request:set_geometry - set window geometry in screen or output coordinates.
• xdg_surface:request:set_output - move a non-fullscreen client surface to a specific display.
  • This may align with existing design principles and precedent.
  • Useful as a coarse window.moveTo(x,y), or some other new API, to move popups and PWA windows to a target display.

See this earlier discussion on #ozone-wayland-x11:

• “In Wayland, clients do not know global screen coordinates. That's why WaylandWindow::GetBounds returns 0,0 position” … “That's a security feature”
  • “you can't know where windows are located on a display. You can only know which display because Wayland sends an event whenever a window changes a display”
• “information [about the position of displays relative to each other] is available and Screen is constructed using that”
• “this will effectively break some existing JS web platform APIs, like window.screenX|Y [1] and window.open's left=x,top=y feature string parameters”
• “It's probably worth compiling an email and sending to Wayland-dev to start a discussion”
• “one can specify display during (maximize?)/fullscreen operation”
• xdg_surface:request:set_window_geometry … is “for insetting the window's visible bounds from a decoration like a shadow” and “may also be used to position a toplevel window relative to each other when they are parented”
• “Wayland compositor decides the initial position of a new toplevel window. Client cannot control that per se. client is only able to set initial size “ … “It should be decided by exo in ash”
• “if a window can't set its global coordinates, it may be useful for a window to at least move itself to a specific display”
  • “it is relatively easy to add this extension. But I would also like to research if a WIP protocol that does that exists”
• “we can do anything we want with exo and come up with any protocol extensions. But do we want to end up with Ozone/Wayland backend that is not comptible with classic Linux wayland approach and result in a very unfriendly and hard maintainable. We should be careful”
  • “One thing is to add something that is new and not yet supported. And another is modifying the original behavior with protocol extensions. I don't really want the second to happen”
    • “something new == protocol extension if it complies with wayland core design and ads new functionality”
  • “To sum up - it sounds ok to me to add an extension that would allow to specify a display where a window should be shown. But it's also worth checking if any WIP protocols exist that already do that.”
  • “creating a new extension to overcome an existing design decision is not something I'd like to support :)”
• Not exposing absolute window position is a design decision https://lists.freedesktop.org/archives/wayland-devel/2015-September/024410.html, but sending a window to a specified display may be allowed but not implemented
• Org_kde_plasma_window:request:send_to_output

How to fail gracefully if coordinate-based placement isn’t supported:

• Best effort, maybe move to display matching coordinates?
• Try to let callers know that coordinate placement isn’t supported?
  • What granularity would this provide? E.g. Wayland lets clients set sizes and choose a display for fullscreen, but not get/set non-fullscreen positions.