Window Activation

https://blog.broulik.de/2025/08/on-window-activation/

by LorenDB • 12 months ago

228 138 12 months ago

blog.broulik.de

zb33• 12 months ago

Umm.. thanks to this logic I had to write an extension just so I could open firefox using a keystroke, because otherwise the browser did not receive focus..

wilkystyle• 12 months ago

Trade-offs abound, but this sounds amazing to me. I already have hotkeys to instantly switch between browser/terminal/Emacs/etc., so it's not an issue for me. What is an issue is some other application stealing focus while I'm typing elsewhere and (as another commenter mentioned) accidentally pressing space or some other key that performs an action in whatever pop-up or application stole the focus.

johnisgood• 12 months ago

You should have focused more! /s /pun intended

But yeah, it has happened to me too, too often for it to be a problem. Especially the press the space bit.

I am not sure this is the right solution, however, but I cannot think of any solution right now.

Someone (in the comments) who has claimed to patch i3 may shed some light on what he did.

antnisp• 12 months ago

I just checked and assigning the shortcut in "System Settings>Keyboard>Shortcuts" will open Firefox and put it in focus.

zb33• 12 months ago

For me in GNOME on Fedora this only works for chromium, for firefox I had to make an extension - I don't know why.

nh23• 12 months ago

This mechanism sounds worth it.

So many times on X11 do I type some chat message, and then some popup from another program comes up, which I accidentally confirm by my typing containing a space which presses the confirmation button, and I don't even know what the popup was.

Or my password being typed in a popup.

I once patched some code into i3 to prevent this for myself, but it wasn't a clean solution.

eqvinox5• 12 months ago

KDE: Settings → Window Management → Window Behavior → Focus → Focus stealing prevention

Even on "Low" (the options are None, Low, Medium, High, Extreme) I'm not seeing this behavior. Might be an i3 problem.

nh23• 12 months ago

Not sure I understand. You acknowledge that I use i3 as window manager, yet suggest settings for another (KWin != i3).

iforgotpassword2• 12 months ago

Huh I'm also on i3 but I never run into this problem. If any program would start stealing focus I'd just uninstall it and yell at the author/vendor.

nh23• 12 months ago

Try

    sleep 2 && zenity --entry --text="Enter text:"

and switch to a different workspace where you start typing.

The popup of the other program should appear and capture your input.

As far as I know, i3 has no prevention for that.

(In this example I'm spawning a program delayed to demonstrate that, but the same can happen to e.g. the gpg-agent password prompt popping up when an SSH connection that uses it reconnects, a chat window from an IM program, and so on. I think the idea of Wayland window activation / focus stealing prevention is that you can still have those windows pop up, but without them taking your input.)

webdevver• 12 months ago

the pragmatic thing to do is just let the Free Market decide. as far as i understand, windows just lets apps grab whatever window they want, whatever input they want, right? and everything Just Works(tm). app writers are discouraged to make things too clever by virtue of users having the choice of not using the app in question.

why cant linux guys just... copy windows?

android-ifying this space with permissions, channels, protocols etc, and pretending that apps are insecure is adding friction that benefits nobody imo.

LorenDB• 12 months ago

Sometimes I type a password into one window, only to have another window pop up partway through and eat the rest of my input. This is why we need to prevent unintentional window activation.

Linkd• 12 months ago

This happens so rarely, that it makes the UX impact to the every day user not worth it in my opinion.

bloomca• 12 months ago

It is relatively easy to replicate if you open 2 apps and start typing in the first one which opened, both on macOS and Windows (I don't use Linux enough to notice this issue).

A proper solution is probably faster startup times, but overall it pretty much never happens? Idk maybe I'm lucky or just conditioned to ignore it.

j1elo• 12 months ago

windows just lets apps grab whatever window they want [...] and everything Just Works

Not really, as proven by the amount of searches with "Windows 11 disable focus stealing" (and ensuing frustration after seeing that it's not a simple toggle somewhere in the Settings) that I've done over time, and confirmed with so many coworkers over the years that we'd like to disable it.

Windows in particular and computers in general, work as they do, and people just adapt to it and sigh in frustration, assuming that things must be that way and there's nothing that can be done to change it. It's difficult to measure "Just Works" if there are no satisfaction surveys for each feature (also would be impractical). Focus stealing in particular is so ingrained in people's minds that I doubt many are even aware that it could work differently.

mathiaspoint2• 12 months ago

It already works that way on X11.

Linux is already set up to handle this better than Windows actually since most apps are open source and abusive window management is likely to result in PRs.

pjmlp2• 12 months ago

Someone has to actually accept and merge them.

burnt-resistor2• 12 months ago

I can only barely appreciate or fathom the endless masochistic self-abuse of maintaining functional, useful semi-headless UI automation testing for various Linux distros.

OsrsNeedsf2P2• 12 months ago

If you did have UI automation, you probably would do it at the DE level, and not swap things like X11 for Wayland. If you don't update (or use something like XFCE), it would probably remain functional for decades

burnt-resistor2• 12 months ago

WTFIDE? (What the fuck is DE?)

dmart2• 12 months ago

As a recent Linux (and Wayland) switcher, I love this behavior. It has always felt insane to me that macOS will just let some random auto-updater steal focus and eat your keystrokes while trying to work on something.

vbezhenar2• 12 months ago

Powerful permissions are needed for powerful apps.

I don't know about this particular issue, but for example, KiCAD has multiple issues with wayland being overly protective: [0]. For example KiCAD needs the ability to move cursor to provide good user experience. KiCAD needs the ability to move and place windows wherever it likes. KiCAD needs to control focus. KiCAD needs to prevent OpenGL throttling on inactive windows. These issues led KiCAD developers to reduce support for Wayland configurations to a bare minimum.

So it's a delicate balance for operating systems to both allow powerful apps to implement complicated UI and to prevent badly written apps to do inconvenient things.

[0] https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support...

nottorp5• 12 months ago

KiCAD needs to control focus.

I don't know what KiCAD is, but it certainly does not need to control focus OS wide. Only between its own windows.

It's probably not KiCAD's fault that the windowing system doesn't work like that, but still...

arghwhat2• 12 months ago

s/KiCAD needs/KiCAD wants/

As a user of KiCAD, I have not found any need for it to automatically move cursors or windows around (nor do I even remember such behaviour pre-wayland, so it can't have been important), but note that the cursor-warp protocol is coming to allow the former, and window tags are coming to allow things like window placement restoration, which should help where this may benefit UX.

Technical note, OpenGL is for rendering, which is unrelated to presentation. Window managers and display servers have no part in that process. It's the Window System Integration (WSI) if used, such as EGL or Vulkan WSI, and in the old days GLX, that talk to the display server.

Wayland only provides an optional suggestion for when it is a good time for a window to render for good frame pacing, latency and performance without the app having a full proper frame scheduling implementation itself. The issue that tends to crop up is that EGL, a WSI often used with OpenGL in apps not using a toolkit, when specifically told to block and wait for next frame, has been internally implemented to use the optional suggestion which is not provided for invisible windows.

Stuff is being done to solve this, and it doesn't affect applications that do not ask to block on updates (say, firefox), nor applications leaving this up to a toolkit (say, Gtk or Qt) or just a different window system integration than EGL (which is extremely limited on its own anyway).

jchw7• 12 months ago

Unfortunately the KiCAD messaging has been a bit messy. They list a spectrum of issues, some of which are very vague and also clearly issues with KiCAD (like "Application freezes and crashes: Instability issues specific to the Wayland environment" - unless the compositor is crashing I fail to see why you would assume KiCAD crashing is an issue with Wayland or your compositor.) On the other hand I don't really blame application developers for being frustrated in general, because a lot of us have been waiting a really long time to see Wayland issues get resolved, and the pace was so slow until recently that it basically felt like it would take an eternity for anything to get resolved. These days though, the pace is very fast, to the point where almost anything written about Wayland will be out of date in a couple of months, mostly for good reasons.

KiCAD needs the ability to move cursor to provide good user experience.

Most applications are implementing pointer warping using pointer-constraints-unstable-v1. This lets you confine the pointer to a region, at which point you can use relative events to get movement, render the cursor yourself and do whatever you want. There is the locked_pointer_v1::set_cursor_position_hint function to allow one to set the location where the cursor should be released at when the constraint is lifted, which should make everything seamless.

And sure, it might actually be that pointer-constraints-unstable-v1 isn't enough for KiCAD's particular UX somehow, maybe they need pointer-warp-v1 or something even more advanced. However, applications generally don't need to set the mouse position to arbitrary locations on-screen at any time... That is a useful capability for something doing automation, but it should really not be needed for general application development.

KiCAD needs the ability to move and place windows wherever it likes.

KiCAD isn't a window manager, it's a damn EDA tool. I do agree that Wayland needs to provide multi-window applications with better tools to hint to the compositor what to do with window placement and especially to save and restore window positions, but this doesn't translate to "applications need to be able to decide where exactly windows go." There is basically no behavior which literally requires this, and certainly no sane behavior that requires this.

Having every application perform its own sort of logic to decide where windows go is a mess everywhere it exists. It would be cleaner and better for users if we could just figure out what sorts of higher level tools applications need for good UX and try to build around that. In most cases merely being able to position windows relative to each-other is enough. (You can obviously do this in Wayland already to some extent, though I'm sure there are missing tools that are needed.)

On Wayland today, applications can't absolutely control window placement, or even know where they are on screen. There really isn't even a global window coordinate space to even leak to applications. It's a pretty radical departure from almost everything else, so yeah, application developers are obviously not thrilled about having to deal with it. But on the other hand, it's probably the right way to go. Just because ability to control absolute positions is convenient does not mean it is necessarily the right way to go, especially if you can provide higher level tools that encode intent better and let the user decide how your application's intent should be interpreted.

KiCAD needs to control focus.

Honestly I have no clue what they're complaining about with focus. It's too vague.

If your application is in the foreground, you can grab an activation token and use it, so even with "extreme" focus protection, there should not be any issues with KiCAD being able to focus its own windows.

As for other software being able to focus itself from KiCAD, well, this article describes how you do it. It's pretty straight-forward and it's not obvious how you would misuse it. Pretty sure the same protocol exists in X11 as well.

They're also talking about modals, which might be related to their complaints. The xdg-dialog-v1 protocol (supported in KDE 6.4, GNOME 48, and used by Qt 6.8+) gives applications the ability to mark dialogs as modals. It is a bit crazy that it took as long as it did for this to become supported by everything, but it did cross the finish line. On Ubuntu 25.04, for example, you should get GNOME 48 and Qt 6.8.

KiCAD needs to prevent OpenGL throttling on inactive windows

OpenGL isn't throttled, it is stalled if the window is entirely occluded. You can now resolve this issue with the fifo-v1 protocol and Mesa 25.0 or newer. For example, Ubuntu 25.04 ships Mesa 25.x and GNOME 48 which has fifo-v1. fifo-v1 is also available in KDE as of 6.4.

This should give applications the frame pacing behavior that they want. It is possible to work around the issue to some degree, it's just annoying.

If KiCAD developers don't want to support Wayland because it's effort they'd rather spend on other shit then fine, XWayland should mostly continue to work as-expected anyways. Best option for now is to force KiCAD to use X11, like Krita does. I'm sure that's not a 100% panacea but it should be good enough especially if KiCAD is so buggy on Wayland that it actively crashes.

gf000• 12 months ago

They are free to create new protocols (or use existing ones) that allow these higher privileged functionality. Then the server implementation will hopefully figure out a decent way to request that permission and the app can then have it.

(Though this permission may be display server-dependent, as it may not make sense in case of each).

dataflow3• 12 months ago

It has always felt insane to me that macOS and Windows will both just let some random auto-updater steal focus and eat your keystrokes while trying to work on something.

Wait, what? Hasn't Windows prevented focus stealing for literally decades at this point?

https://devblogs.microsoft.com/oldnewthing/20090220-00/?p=19...

dmart2• 12 months ago

Ah, that may be the case - I’ll edit my comment. I was primarily using macOS before this so I may have misremembered the Windows behavior.

jenscow• 12 months ago

An app can still steal focus with `uiAccess=true` in the app manifest's execution level (and the app is signed).

ack_complete3• 12 months ago

It used to block focus stealing aggressively unless a program had foreground permission or was given it (AllowSetForegroundWindow), but the mechanism seems broken in current versions of Windows.

mayoff• 12 months ago

Supposedly this was improved in macOS 14 (Sonoma, late 2023) with "cooperative app activation". It's discussed in this WWDC 2023 video:

https://developer.apple.com/videos/play/wwdc2023/10054/?time...

xp844• 12 months ago

Since it's usually Apple's own OS stuff usually to blame with their incessant "GIVE ME YOUR PASSWORD... something something updates" dialogs, I won't hold my breath.

Defletter• 12 months ago

Yup. I used to use a Macbook Pro as my daily driver and played League of Legends on it... and the amount of forced-focus was infuriating. You just locked in and are messaging your friend on Discord about something? Well, there's 10 seconds left until the game starts and that's more important so you're focusing the League client now.

bityard• 12 months ago

I have either approved or denied about a dozen things on my MacOS work laptop and have no idea what they were because I was in the middle of typing a sentence and happened to hit the spacebar when the dialog popped up. Hope none of them were too important!

b2m9• 12 months ago

Good to hear I’m not the only one with issue.

yard2010• 12 months ago

This could be a nice attack vector maybe, gray app can prompt you to type something and show this window 0.1 sec before you hit the spacebar.

mmis1000• 12 months ago

If it does just let anything get the focus than it is still somewhat okay. The worst thing is you open a folder from some other app and nothing happens, the desktop did not switch to finder at all. And after you switched it manually. The whole ten windows opened at same time.

pmarreck• 12 months ago

Windows was worse at this than the Mac was.

throwaway20372• 12 months ago

Seriously question about focus stealing: What is state of the art at the moment for desktop windowing systems? Is the "correct" action when a window wants to steal focus: Pop under the active window and give a non-focus stealing hint (UI balloon?) to the user that this window needs attention?

I can think of two real world examples: (1) debugger hits breakpoint and steals focus (this is sometimes configurable), (2) WiFi needs re-/auth.

jabiko• 12 months ago

I don't think there should be a "correct" way to steal focus. When I'm editing a document, I don't want _any_ application to steal focus. I don't want a window to show up and steal focus when something needs reauthentication. Maybe the developer of an application thought that his use case is of the very utmost urgency and requires immediate action. I don't agree. Just notify me over the standard way that the system provides and I will deal with it when I want to.

For the debugger use case: If the IDE has already focus, it can pass an activation token to the debugger and the debugger can use this to focus itself. If the IDE is not focused, I don't want the debugger to steal focus.

nottorp5• 12 months ago

I don't understand who historically has thought it's a good idea to allow applications to steal focus in the first place. It should be the window manager's decision, and the window manager should only switch focus if the user decides that.

guardian5x• 12 months ago

Well, sometimes the user expects the focus to shift, like the example mentioned when you click a link in one application and your browser in the background should come into focus when it opens a new tab. Some applications just decide to steal focus when the user does not expect it, and that is the problem.

nottorp5• 12 months ago

Yes but there's no way for the OS to know if the focus request is legitimate, is there?

Can't even say "browsers are allowed to grab focus" because they'll grab it for a stupid window telling you to update the browser or what new features no one cares about they introduced.

I'd prefer to have to switch focus to the browser manually than have the stupid ubuntu update manager steal focus when i'm typing in the terminal...

BobaFloutist2• 12 months ago

If you click a link in one application, surely it should pass focus to the browser, why should the browser be initiating that process?

somat• 12 months ago

I am not sure, as a convert to the church of "focus follows mouse" I sort of want well... my focus to follow the mouse and the mouse to follow me.

Now there may be a legitimate case to steal focus, but I am unable to think of one at the moments and your click link example fails to convince me.

I also sort of hate modal dialogs/windows. I think modals are in general an indicator of lazy/bad design. That being said, there are legitimate cases for modals. but "stop the world and handle me" should be a last resort not the first.

eqvinox5• 12 months ago

KDE has KWin settings controlling this. I have no idea if this is some kind of a fixup after the fact or whether the window manager always controls this, but at least it does on a KDE X11 session.

SoftTalker• 12 months ago

You think that's bad, back in the day when I was in an office where everyone used X terminals off of a common unix server, you could open a window on someone else's screen by just changing your DISPLAY environment variable. Fun pranks were fairly common.

sho_hn2• 12 months ago

Earlier discussion with comments from devs https://news.ycombinator.com/item?id=44784312

anonym295• 12 months ago

[flagged]

eddythompson803• 12 months ago

Wait, you can do that in X11 too... Is X11 spyware??? I know there is xeyes.. Is it..

anonym295• 12 months ago

In the past, I would've said no. It absolutely had severe vulnerabilities, no question about it. Anything in userland monitoring keystrokes, mouse input, and display of anything else is userland is genuinely concerning; that said, these were byproducts of architectural decisions made long ago in open source software - not quite the same as deliberately writing code explicitly and specifically to take away privacy and control from your users the way Microsoft and Apple do.

These days however, the negligence of the current custodian, Red Hat, does seem to border on malicious, especially when forks like XLibre are continuing to patch vulnerabilities while Red Hat refuses to merge patches into the "official" X11, as part of a coercive strategy of trying to force all users onto Wayland by allowing X11 to become even worse through active refusal and neglect to merge good PR's with security patches, despite being the official project owner and custodian.

As a final note, I did not say that Windows and Mac OS were spyware, I said they were functionally spyware. There's a meaningful and nuanced difference between those two claims that I'm not sure you are discerning in accordance with my intent.

Pesthuf• 12 months ago

…if that was the reason, why would the operating systems give other applications the right to steal focus and record keystrokes? They control the kernel, they don’t need that.

anonym295• 12 months ago

Habituate and condition users to abuse and lack of control. No pressure for OS developers to respect the agency of their users.

tomhow3• 12 months ago

We detached this subthread from https://news.ycombinator.com/item?id=44836873 and marked it off topic.

rs186• 12 months ago

Clicked the article because my blurry eyes read "on Windows Activation", and I was like "huh, what's interesting about Windows activation?"

Read the first paragraph and it was really confusing. Still the same after reading it again.

Until I looked at the title. Oh, window activation is what we are actually talking about.

andrewmcwatters2• 12 months ago

I too was hoping for something like a deep dive into key management reverse engineering. lol

userbinator• 12 months ago

xp844• 12 months ago

Don't feel bad -- the other frontpage story "ultra thin business card runs fluid simulation" I thought it said "...RUINS fluid simulation."

wavemode• 12 months ago

I'm worse than you - when I came across that article, I spent a while wondering whether "ulathrin" was the name of a company, or some new metal alloy. Your comment is what made me realize I misread it.

DonHopkins• 12 months ago

They used to have whole conferences on window management!

"Methodology of Window Management": http://www.chilton-computing.org.uk/inf/literature/books/wm/...

By F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985. This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme. The Proceedings were later published by Springer-Verlag in 1986.

My favorite chapters:

"Ten Years of Window Systems - A Retrospective View" by Warren Teitelman: http://www.chilton-computing.org.uk/inf/literature/books/wm/...

"SunDew - A Distributed and Extensible Window System" by Games Gosling: http://www.chilton-computing.org.uk/inf/literature/books/wm/...

"User Interface Working Group Discussions": http://www.chilton-computing.org.uk/inf/literature/books/wm/...

"User Interface Working Group Final Report": http://www.chilton-computing.org.uk/inf/literature/books/wm/...

heraldgeezer• 12 months ago

Haha exactly why I am here too. I need glasses.

361994752• 12 months ago

I have my glasses and still got here :(

mdavid626• 12 months ago

Same.

eirikbakke• 12 months ago

If that's the topic you were looking for, you may like this "Dave's Garage" episode, where a retired Microsoft engineer talks about implementing... Windows Activation. https://www.youtube.com/watch?v=FpKNFCFABp0

zulu-inuoe• 12 months ago

I thought exactly the same thing

fn-mote• 12 months ago

Yes, appending “in Wayland” would have 1000% clarified the topic for me.

jovial_cavalier• 12 months ago

Stealing focus is possible in X11, but the window manager needs to implement it. For instance, my dwm build does not refocus for any reason other than the user moving the mouse or pressing a key

rekabis• 12 months ago

This title seems click-baity, as the term is most frequently used for registering Windows. That was my curiosity when I clicked through. I somehow doubt it would have gotten as many clicks had it been “Window Focus”.

OsrsNeedsf2P2• 12 months ago

I don't think Linux users, much less Linux desktop developers, are thinking about Windows license activation.

satiric• 12 months ago

There is no indication in the title that this is about Linux.

sho_hn2• 12 months ago

It's called window activation in the standard protocol the blog is about, so it's technically correct terminology.

andrewmcwatters2• 12 months ago

It's not just windows that I love popping up in my face actively! interrupting what I'm doing, but also ones that have autofocus elements, doubly stealing my attention and not having a debounce for ignoring actions, as others here have mentioned.

Type-type-type...HEY THIS APPLICATION HAS SOME UPDATES HERES A CHANGEL-keypress closes window

I wanted to read that, damn it!

treve• 12 months ago

Great idea, but pretty painful at the moment. I guess not everything uses this protocol yet, so I often can't find (for example) my password pops under other windows. Hoping this gets a bit better over time, it's one of the last remaining Wayland pains.

wronex• 12 months ago

Wait, hold on. Is this actually an issue that needs a solution? It feels like Wayland is doing something very stupid here. Why not let apps control their windows? I cannot remember when an app stole focus last time. The only time this makes sense is while entering a password. But that is a very specific case that can be solved by having the password dialog on a protected desktop (ie. one with only that single window.)

chmod7752• 12 months ago

I cannot remember when an app stole focus last time.

You must not use Windows where every application comes with its own auto-updater, often stealing focus and minimizing your game once when the updater pops up, and then again when it restarts the main application it just updated.

Devs can't be trusted to not turn their users homicidal. Someone has to stop them for their own good.

eqvinox5• 12 months ago

Well, you probably know by now that Wayland, unlike X, doesn’t let one application force its idiot wishes on everyone else.

…I thought {not allowing,managing} this on X11 is the window manager's job? (kwin certainly doesn't allow it on my X11 session…)

Or is this arguing about "uncooperative"/"hostile" applications?

imchillyb• 12 months ago

The power of a system does not lie within its mechanisms, systems, and strategies.

The power of a system allows one -near infinite- ability to create and manipulate those mechanisms, systems, and strategies.

The most powerful systems have few safeguards or rails, and user beware.

The most restrictive systems we hand to grandma and grandpa, knowing there is little they can actually do with them.

josteink• 12 months ago

In essence, an application cannot take focus, it can only receive focus. In the example above, your chat app would request an XDG Activation token from the compositor

To be fair, the same is mostly true on Windows, but through some different APIs.

Applications being able to put themselves in front unconditionally was for a long time a huge source of pain for the user, due to abusive/malicious software, and probably a reason Windows was malware platform #1.

This is honestly a reasonable design.

chmod7752• 12 months ago

On my my glorified gaming console (Windows desktop PC) it drives me absolutely nuts when I'm in the middle of some competitive game and a random auto-updater pops up, minimizing my current current fullscreen application. Bonus points if it happens again 30 seconds later because it launches the application after updating it (Why? I didn't even have it open before!)

In some cases this had to get past QA at two billion-dollar companies, and neither did something about it.

But that's far from the only way we've regressed in software quality. Really not worth mentioning. A drop of piss in an ocean of sewage.

I'm glad that at least on my actual computer I get to focus on work distraction free - likely because most of the software running on there is designed by its users and survived by merit, rather than being the brainfart of some corporate committee more concerned with other things.

Window Activation

Related Stories