No way to avoid focus stealing on X11.

[Toqozz]

There seems to be no way to map a window without focusing it. I've only tested this on X11, but it may be present on other platforms as well given there is no WindowBuilder option to disable the behaviour.

On X11, this code is the culprit:

winit/src/platform_impl/linux/x11/window.rs

Lines 353 to 358 in b03e589

	// Set visibility (map window)
	if window_attrs.visible {
	unsafe {
	(xconn.xlib.XMapRaised)(xconn.display, window.xwindow);
	} //.queue();
	}

XMapRaised pushes the window to the top of the stack as well as maps the window.

There should be an option to disable this behaviour and map the window normally with XMapWindow().

[murarth]

I've run a quick test, changing both instances of XMapRaised (one in Window::new, the other in Window::set_visible) to XMapWindow and the window still steals focus when mapped. I suspect this is due to window manager behavior and likely varies from WM to another and may be affected by WM configuration.

Also, I'm a bit confused about the use case for this. Why would one want to create a window that does not steal focus?

[Toqozz]

It looks like there's more than one culprit. This code seems to focus the window again after mapping it:

winit/src/platform_impl/linux/x11/window.rs

Lines 436 to 441 in d35ee0d

	(xconn.xlib.XSetInputFocus)(
	xconn.display,
	window.xwindow,
	ffi::RevertToParent,
	ffi::CurrentTime,
	);

When I comment that code out, it allows the window to be mapped without stealing focus. (for testing, try with_x11_window_type(XWindowType::Notification) to avoid the window manager focusing it for you.)

Actually, I can't find a difference in behaviour between XMapRaised and XMapWindow on my WM (bspwm); they both either steal focus or don't steal focus depending on window type. I suspect that XMapRaised might actually mean raise window within subwindows, or maybe the behaviour differs between window managers.

The problem is that the code I linked above seems to focus the window regardless of window type.

Also, I'm a bit confused about the use case for this. Why would one want to create a window that does not steal focus?

Some examples include notification windows and tooltips. It's pretty annoying for a notification to steal focus and stop you from being able to type, and similarly tooltip windows could stop you from using shortcuts (not to mention the jankiness of the window getting greyed out every time a tooltip pops up).

[murarth]

Some examples include notification windows and tooltips.

Oh, I didn't realize a tooltip was its own window. It seems so obvious now.

Anyway, I tracked down the commit that introduced the code you referenced and I ended up at this issue: rust-windowing/glutin#509

It seems that the XSetInputFocus call was first introduced to fix an issue with fullscreen windows not receiving any keyboard input. As such, I believe the code could be changed to call XSetInputFocus only when Window::set_fullscreen is called. This way, all applications should experience correct behavior without having to jump through the hoops of explicitly disabling focus stealing.

I'll get started on a PR for this tomorrow.

[OvermindDL1]

Actually, I can't find a difference in behaviour between XMapRaised and XMapWindow on my WM (bspwm); they both either steal focus or don't steal focus depending on window type. I suspect that XMapRaised might actually mean raise window within subwindows, or maybe the behaviour differs between window managers.

As per the docs:

The XMapRaised() function essentially is similar to XMapWindow() in that it maps the window and all of its subwindows that have had map requests. However, it also raises the specified window to the top of the stack.

So yes, of the group of windows in the stack it also raises it to the top.