We might be able to do something to prevent focus stealing, but fwiw the problem exists in sway as well. Easiest solution is probably to run mate-notification-daemon, which I ported to layer shell a while back.

Easiest solution is probably to run mate-notification-daemon, which I ported to layer shell a while back.

Looks like it wants to be DBus-activated, as it silently exits a few seconds after starting...

Looks like it wants to be DBus-activated, as it silently exits a few seconds after starting...

Hmm, it even is DBus-activated I think. Still shows up in the middle of the screen, though.

Hmm, it even is DBus-activated I think. Still shows up in the middle of the screen, though.

It won't have access to zwlr_layer_shell unless started from miriway-shell, so try enabling add-wayland-extensions=all and see if that works

It won't have access to zwlr_layer_shell unless started from miriway-shell, so try enabling add-wayland-extensions=all and see if that works

Bingo!

I've modified the bug to talk about focus stealing prevention only.

Bingo!

Well, assuming we don't want to allow zwlr_layer_shell et alias to all applications Miriway needs a way to "whitelist" such services. (Might nor might not be a Mir issue too)

Quick reformulation of the issue: As we have xdg-activation implemented now, there's no need to automatically focus and bring new windows to the front. xdg-activation can then raise and focus windows when it's appropriate.

I've tracked what's needed down to two places, these may not be the proper places to modify, but are a start:

1. MinimalWindowManager::handle_window_ready. This part is responsible for focusing new windows.
   

   mir/src/miral/minimal_window_manager.cpp

   Lines 127 to 133 in 3c9a7c6

   	void miral::MinimalWindowManager::handle_window_ready(WindowInfo& window_info)
   	{
   	if (window_info.can_be_active())
   	{
   	tools.select_active_window(window_info.window());
   	}
   	}

   
   Should never enter this if condition unless there are no other windows.

2. SurfaceStack::insert_surface_at_top_of_depth_layer. This is responsible for the placement of a window within a depth layer.
   

   mir/src/server/scene/surface_stack.cpp

   Lines 513 to 519 in 3c9a7c6

   	void ms::SurfaceStack::insert_surface_at_top_of_depth_layer(std::shared_ptr<Surface> const& surface)
   	{
   	unsigned int depth_index = mir_depth_layer_get_index(surface->depth_layer());
   	if (surface_layers.size() <= depth_index)
   	surface_layers.resize(depth_index + 1);
   	surface_layers[depth_index].push_back(surface);
   	}

   
   Should only insert at the end for the first window, all subsequent surfaces should be behind it.

Modifying these two pieces of code to not automatically focus and push new windows to the front should allow xdg-activation to do so when it's appropriate.

What's missing: Creating and passing some sort of strategy down to control the behavior depending on whether xdg-activation is available or not. One approach could be using mir::scene::Surface to carry this information since it can be accessed through (1), and can be exposed via WindowInfo -> WindowInfo::Self -> Window -> Window::operator std::shared_ptr<mir::scene::Surface>() in (2) (though I think we don't have direct access to the surface in this case for a reason)

As for X11 applications, those are another can of worms. Now we need the logic to also depend on the app type (wayland vs X), and figure out how XWayland handles this.

One thing I'm realizing re-reading xdg-activation-v1 is that it only applies to applications launched from other applications. So at the moment with the changes mentioned applying to all applications, applications launched through shortcuts will not start focused (can be worked around)

Opening links is launching (or activating, if already running) applications from other applications. That just requires things to work together and pass the token further.

This was actually the use case Matt implemented activation for.

Oh I think I should've elaborated more. I didn't mean URLs when I mentioned shortcuts. I meant Mir's shortcuts (CTRL+ALT+T for example)

Oh I think I should've elaborated more. I didn't mean URLs when I mentioned shortcuts. I meant Mir's shortcuts (CTRL+ALT+T for example)

Yes, we need to update our launch code to supply a token we respect

Some things that broke with the changes above:

1. Since window offsets are based off the currently open window, only the second window is offset, and all windows launched after the second window are positioned at the exact same position.
2. Xterm (probably all server-decorated apps) are borked
   

2. SurfaceStack::insert_surface_at_top_of_depth_layer. This is responsible for the placement of a window within a depth layer.

mir/src/server/scene/surface_stack.cpp

Lines 513 to 519 in 3c9a7c6

	void ms::SurfaceStack::insert_surface_at_top_of_depth_layer(std::shared_ptr<Surface> const& surface)
	{
	unsigned int depth_index = mir_depth_layer_get_index(surface->depth_layer());
	if (surface_layers.size() <= depth_index)
	surface_layers.resize(depth_index + 1);
	surface_layers[depth_index].push_back(surface);
	}

Played around with it for a bit, this is not the way.

Edit: Crisis averted. This modification doesn't break literally everything using the stack now

@@ -106,7 +106,7 @@ auto ms::ApplicationSession::create_surface(
     auto surface = surface_factory->create_surface(session, wayland_surface, streams, params);
 
     auto const input_mode = params.input_mode.is_set() ? params.input_mode.value() : input::InputReceptionMode::normal;
-    surface_stack->add_surface(surface, input_mode);
+    surface_stack->add_surface_below_top(surface, input_mode);
 
     if (observer && observer_executor)
     {

Spent a fair bit of time trying to figure out a way to propagate the information that xdg_activation_v1 (or really, whatever extension needs to be checked) down to BasicWindow so it can be used in handle_window_ready. This was done through exposing Server::is_wayland_extension_enabled, and adding miral::ExtensionLookup so it can be used in miral.

At the moment, I'm a bit lost how to do this with ApplicationSession::create_surface (check previous comment). The most obvious way after a quick glance of the stack trace and code would be to pass the info through SessionManager's constructor, then through ApplicationSession's constructor, then using it in create_surface.

Anyway, once this is done, we'll need to cover two more things (in addition to the stuff mentioned a couple of comments ago):

1. Automatically focusing applications launched through Mir. I took a quick look at this and the only piece of information we get regarding those is the PID of the application. Not sure if this is very useful.
2. Xwayland applications: No clear idea what needs to be done.

Spent a fair bit of time trying to figure out a way to propagate the information that xdg_activation_v1 (or really, whatever extension needs to be checked) down to BasicWindow so it can be used in handle_window_ready. This was done through exposing Server::is_wayland_extension_enabled, and adding miral::ExtensionLookup so it can be used in miral.

I think this approach is problematic: We have APIs that allow shells fine grained control over enabling extensions (c.f. miral::WaylandExtensions::conditionally_enable(), so there is no way to implement Server::is_wayland_extension_enabled et alia to produce reliable results. Also, as you have noted, it requires significant work to propagate the results to where they would be useful.

I would reverse the dependency: if "focus stealing prevention" is enabled in miral, then force xdg_activation_v1to be enabled.

I would reverse the dependency: if "focus stealing prevention" is enabled in miral, then force xdg_activation_v1to be enabled.

Or even, just allow the options to be independent: even if not the desired end state, that makes experimentation easier

allow the options to be independent

That may well be the best — --require-activation or so, and no connection to the activation protocol?

Spent some time passing things (ExtensionLookup) to ApplicationSession so surfaces can be inserted at the proper place in the stack. I also spent some time trying out different applications just to have an idea which use xdg-activation-v1.

After that, Alan, Sawicz, and I spent some time discussing whether I was going the right way and using Mir's existing customization options properly or not (hint: I was not). So, seeing how alt+tab did something similar to what we did, we agreed that this was a good place to start and figure out if FloatingWindowManagerPolicy needed any changes to expose that so it can be customized in it. The next step would've been to then add a new constructor for FloatingWindowManagerPolicy to toggle between the old and new logic.

I spent some time reading through c2553c5 to get a basic idea how alt + tab was implemented, figured that WindowManagerTools::swap_tree_order was the missing piece, and figured out what to do to disable auto raising (just swap the new window on top with the already existing one) + focusing (at least for all applications after the first, makes it easier to test :)). Was trolled a bit by kgx actually raising windows because I forgot to disable xdg-activation :P

As of right now, this is done with a few lines in FloatingWindowManager, but I believe that I discovered a bug? where the next window in the stack is not focused whenever we close the one above it. I'm not sure of the root cause at the moment.