[HN Gopher] Window Activation
___________________________________________________________________
Window Activation
Author : LorenDB
Score : 163 points
Date : 2025-08-04 12:03 UTC (4 days ago)
(HTM) web link (blog.broulik.de)
(TXT) w3m dump (blog.broulik.de)
| zb3 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I just checked and assigning the shortcut in "System
| Settings>Keyboard>Shortcuts" will open Firefox and put it in
| focus.
| zb3 wrote:
| For me in GNOME on Fedora this only works for chromium, for
| firefox I had to make an extension - I don't know why.
| nh2 wrote:
| 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.
| eqvinox wrote:
| 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.
| webdevver wrote:
| 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 wrote:
| 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 wrote:
| This happens so rarely, that it makes the UX impact to the
| every day user not worth it in my opinion.
| Barbing wrote:
| Fellow macOS users: is this rare for you as well?
|
| Maybe an auto-updater will do this, and if it happened with
| any frequency I might disable those autoupdates and try a
| macro-based (e.g. Keyboard Maestro) solution.
| LandR wrote:
| Windows stealing focus happens to me multiple times a day
| on Windows when I'm working.
|
| It's infuriating.
| bloomca wrote:
| 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 wrote:
| > _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.
| mathiaspoint wrote:
| 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.
| pjmlp wrote:
| Someone has to actually accept and merge them.
| mathiaspoint wrote:
| Not necessarily. The fork could get packaged instead if the
| users prefer it.
| pjmlp wrote:
| As history has proven multiple times, most forks fail,
| after those that made them in first place lose interest
| keeping up with upstream, while others appreciate the
| fork as long as they aren't the ones actually doing the
| work.
| pxc wrote:
| You're right, but it's not unusual for distro maintainers
| to carry patches for one or two removing an obnoxious
| behaviors for a long time.
| burnt-resistor wrote:
| 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.
| OsrsNeedsf2P wrote:
| 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-resistor wrote:
| WTFIDE? (What the fuck is DE?)
| eqvinox wrote:
| Desktop Environment
| dmart wrote:
| 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.
| vbezhenar wrote:
| 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...
| nottorp wrote:
| > 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...
| suspended_state wrote:
| The page states:
|
| > Unpredictable window focus behavior that can interrupt
| workflows
|
| Which isn't exactly the same issue, so indeed it doesn't
| need to control focus.
| nottorp wrote:
| That sounds like my problem with focus being stolen by
| random apps while i work :)
| arghwhat wrote:
| 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).
| vbezhenar wrote:
| > As a user of KiCAD, I have not found any need for it to
| automatically move cursors
|
| Well, the first thing you do with KiCAD is scrolling to
| zoom in and out, and KiCAD scroll works in a way to jump
| cursor to the center, so you basically can pan and scroll
| at the same time. That's default behaviour unless you
| changed it in the settings, and, obviously, it needs to
| warp cursor to the center of the window.
| jchw wrote:
| 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.
| magicalhippo wrote:
| As I understand it, a big issue for KiCAD is that it's old,
| so they went with WxWidgets as Qt wasn't a viable
| option[1].
|
| It's also a conglomerate of executables, so focus transfer
| often won't be between windows in the same process, but
| windows in different processes.
|
| [1]: https://forum.kicad.info/t/what-is-the-future-of-
| wxwidgets/2...
| jchw wrote:
| I don't think it's absolutely necessary to move off of
| wxWidgets for Wayland support to be in decent shape in
| the long run. There is definitely a path forward that
| wxWidgets can improve its Wayland support, or KiCAD can
| add its own specific Wayland support bits to work around
| what wxWidgets can't do, if they want. It might take
| time, but that's OK...
|
| There's different ways to approach it that are equally
| pragmatic. Any of these approaches, possibly a
| combination of them, seem totally reasonable to me:
|
| - Force X11, or at least prefer it when DISPLAY is non-
| empty. Probably also display a warning when loading on
| Wayland, since the experience is known to be sub-optimal.
| Let things sit for a while until Wayland looks mature and
| well-supported enough to basically rip off the bandage.
| This is a good option for most programs. Krita is doing
| this. Users understand this, other developers understand
| this, etc.
|
| - Make specific efforts to support existing Wayland
| compositors even in spite of its limitations. Godot has
| been doing borderline heroic things to make Wayland
| first-class (check out how they're working around the
| lack of something like XEmbed - it's pretty intense.)
|
| - Participate in the process of proposing Wayland
| protocols or new versions of existing protocols to fill
| in holes gradually. It's not a fun process anymore than
| any other standards process, but it's a way you can help
| the entire ecosystem out and impart some of your
| knowledge/experience into the protocol design in the
| process.
|
| And ultimately, I don't really think there's anything
| wrong specifically with listing the problems that a
| program has when running under Wayland, it's very helpful
| to have a list that people can keep track of over time
| (like KDE's old "Wayland showstoppers"[1] page.) I do
| think that KiCAD's current list is overly opinionated on
| what the true root issue is even when it's subjective. I
| think it's better to frame things more in line with what
| doesn't work and a first-order "why" - i.e. "Pointer
| wrapping does not work because the current implementation
| in KiCAD relies on being able to set the absolute
| position of the cursor which is not available on
| Wayland." "There are currently stability issues on
| Wayland that don't occur on X11." etc. whereas now it
| feels like it's just a list of complaints, sometimes
| without enough information to know what the actual issues
| might even be.
|
| I personally don't like wxWidgets very much, but it does
| have its advantages, and I'm sure a future can be built
| to be able to update wxWidgets applications to run
| smoothly on Wayland and maybe other future window
| systems, possibly by adding some new abstractions and
| tools.
|
| > It's also a conglomerate of executables, so focus
| transfer often won't be between windows in the same
| process, but windows in different processes.
|
| While that does complicate things, it's pretty tractable
| with some IPC. If you only need to change focus when
| `exec`ing (consider: this might be the case even when
| there's already a window open, if you're using something
| to do single-instancing) then it's even simpler as you
| can use the "standard" approach of passing the token via
| en environment variable on exec (then IPC'ing it to the
| instance in a single-instance situation.) I think this is
| what you want to do anyway on Linux right now, not just
| on Wayland.
|
| [1]: https://community.kde.org/Plasma/Wayland_Known_Signi
| ficant_I...
| magicalhippo wrote:
| > There is definitely a path forward that wxWidgets can
| improve its Wayland support
|
| Seems there's some willingness[1] to do just that.
|
| > or KiCAD can add its own specific Wayland support bits
| to work around what wxWidgets can't do, if they want
|
| From what I gather the KiCAD devs are very much against
| that, as it would detract manpower from the core product,
| ie KiCAD itself, which is understandable.
|
| > whereas now it feels like it's just a list of
| complaints, sometimes without enough information to know
| what the actual issues might even be
|
| Then again, I can understand their frustration. Wayland
| makes Python 2 to Python 3 seem like a well-executed
| transition. Wayland is soon older than X11 was when
| Wayland got started, and it's still a mess.
|
| Though as you say, it feels (as a user) like it's
| improving a lot more lately. So I think the strategy of
| the KiCAD devs to essentially ignore Wayland for a bit
| longer is a good one. In a few more years support all
| around is likely a lot better, and then it might make
| sense to spend a bit of time adding bespoke Wayland code
| to KiCAD.
|
| [1]: https://gitlab.com/kicad/code/kicad/-/issues/7207#no
| te_14094...
| jchw wrote:
| > Seems there's some willingness[1] to do just that.
|
| I'm glad the wxWidgets developers are being helpful here.
|
| > Wayland is soon older than X11 was when Wayland got
| started, and it's still a mess.
|
| To me the Wayland transition is less about Wayland and
| more about finally breaking the dependency on X.org. It
| was a long, long, long time coming, and there were _a
| lot_ of prerequisites to get there. KMS, DRM, EGL, GBM,
| dmabufs, libinput, etc.
|
| I believe the immutable aspects of Wayland are perfectly
| serviceable and it should have a good shelf-life. I hope
| to see more advantage taken of the fact that Wayland is
| capabilities-based, more edge-cases of protocols nailed
| down, and I also hope the Newton accessibility bus sees
| more development as it seemed very promising.
|
| I realize people are upset at how long things take. In my
| opinion, community-driven open source is pretty good at
| long-term things and bad at short-term things. The
| Wayland color-management MR took _five years_ , but
| paging through the threads it's easy to appreciate the
| amount of thought that went into it and feel like it
| really lays a solid foundation for the future. With
| desktop systems evolving about as slowly as ever, I think
| this a tractable situation, and being a daily driver of
| Wayland on several devices I feel like it's been a long
| time since I felt the free software desktop was this
| close to parity with the competition in terms of features
| and to some extent, even productivity, dare I say. (I
| really like what KDE Plasma has done.) I honestly think
| the most major blocker for Wayland remains full parity
| for NVIDIA devices, and from that point forward the real
| main challenge for the Linux desktop will go back to
| being software and hardware support as it arguably once
| was.
| gf000 wrote:
| 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).
| anonym29 wrote:
| >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
|
| What's so crazy about that? Windows and Mac OS are already
| _functionally_ spyware posing as operating systems, as
| Microsoft and Apple are _functionally_ intelligence agency
| partners posing as private corporations.
| eddythompson80 wrote:
| Wait, you can do that in X11 too... Is X11 spyware??? I know
| there is xeyes.. Is it..
| anonym29 wrote:
| 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.
| eddythompson80 wrote:
| I don't know man. I think there is a much simpler
| explanation than the crazy fan fic your writing there.
| anonym29 wrote:
| Can you be more specific about what parts of my
| perspective appear crazy, or fan-fic to you? There is
| heaps of well-documented evidence from reputable sources
| to support all of my claims that I would be eager to
| offer. What specific claims do you find dubious?
| Pesthuf wrote:
| ...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.
| anonym29 wrote:
| Habituate and condition users to abuse and lack of control.
| No pressure for OS developers to respect the agency of
| their users.
| SkiFire13 wrote:
| > Habituate and condition users to abuse and lack of
| control
|
| We could say the same about X11, no?
| dataflow wrote:
| > 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...
| dmart wrote:
| 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 wrote:
| An app can still steal focus with `uiAccess=true` in the app
| manifest's execution level (and the app is signed).
| ack_complete wrote:
| 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 wrote:
| 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...
| xp84 wrote:
| 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 wrote:
| 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 wrote:
| 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!
| mmis1000 wrote:
| 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 wrote:
| Windows was worse at this than the Mac was.
| nottorp wrote:
| 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 wrote:
| 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.
| nottorp wrote:
| 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...
| elehack wrote:
| The article is about a mechanism for the OS to validate
| focus requests. The application with the link requests a
| focus token, and passes it to the browser along with the
| open-link request, and the browser can then request focus.
|
| It isn't perfect, because there's no way to know that the
| browser isn't using the token to request focus for
| something else, but maintaining and validating chain of
| custody for focus across applications is exactly the
| problem it looks like they are working on solving.
| xp84 wrote:
| That was exactly the example given in the article, but
| somehow this isn't what I expected would happen if I
| click a link in say, my email client or chat program.
|
| I imagined it more like: User clicks link in email
| program. Email program tells OS: "Here, open https://..."
| -- OS checks URL scheme registry and selects Firefox, OS
| brings Firefox to the front and throws the URL at it and
| says "Open this."
|
| I guess perhaps my naive way could falls down if the OS
| accepts URLs from apps that aren't in the foreground, so
| a random background process could activate any app it
| wants to steal focus.
| elehack wrote:
| Yep. With the solution discussed, as I understand it, the
| e-mail program just needs to be modified to request a
| focus token and send it along with the URL request to the
| browser or the OS browser dispatch service to keep the
| expected behavior.
|
| This could be abstracted by libraries (e.g. a method in
| Qt to open a URL in the system browser automatically gets
| the token) so each application doesn't need to be updated
| separately, or possibly even OS services.
| Ukv wrote:
| > 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 [...]
|
| To my understanding, the approach described in the article
| is that the currently active program requests a token and
| then passes that along to the program that it wants to take
| focus. Compositor can also check what triggered the request
| (mouse click? global keybind?) to decide if the request is
| legitimate.
|
| That seems reasonable to me, opposed to requiring the user
| to switch over to a new window every time they `right click
| -> show in file browser` a file in their IDE, or after they
| press a hotkey to open a screenshot tool, or so on.
| nottorp wrote:
| > Compositor can also check what triggered the request
| (mouse click? global keybind?) to decide if the request
| is legitimate.
|
| That's what I'm dubious about. But I haven't look at the
| details ofc.
| BobaFloutist wrote:
| If you click a link in one application, surely it should
| _pass_ focus to the browser, why should the browser be
| initiating that process?
| watusername wrote:
| Only the invoked app knows whether it needs the focus in
| the first place. Maybe the link you clicked is supposed to
| initiate some background processing that does not demand
| your focus at all.
| BobaFloutist wrote:
| Sure, so the previous app can give the option to take
| focus to the browser which can take it or not as it
| wishes.
| somat wrote:
| 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.
| eqvinox wrote:
| 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 wrote:
| 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_hn wrote:
| Earlier discussion with comments from devs
| https://news.ycombinator.com/item?id=44784312
| rs186 wrote:
| 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.
| andrewmcwatters wrote:
| I too was hoping for something like a deep dive into key
| management reverse engineering. lol
| userbinator wrote:
| You may like this: https://sabah.forumotion.com/t333-all-you-
| need-to-know-about...
| xp84 wrote:
| Don't feel bad -- the other frontpage story "ultra thin
| business card runs fluid simulation" I thought it said
| "...RUINS fluid simulation."
| wavemode wrote:
| 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 wrote:
| 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 wrote:
| Haha exactly why I am here too. I need glasses.
| 361994752 wrote:
| I have my glasses and still got here :(
| mdavid626 wrote:
| Same.
| eirikbakke wrote:
| 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
| jovial_cavalier wrote:
| 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 wrote:
| 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".
| OsrsNeedsf2P wrote:
| I don't think Linux users, much less Linux desktop developers,
| are thinking about Windows license activation.
| sho_hn wrote:
| It's called window activation in the standard protocol the blog
| is about, so it's technically correct terminology.
| andrewmcwatters wrote:
| 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 wrote:
| 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 wrote:
| 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.)
| eqvinox wrote:
| > 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 wrote:
| 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 wrote:
| > 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.
___________________________________________________________________
(page generated 2025-08-08 23:00 UTC)