this post was submitted on 25 Apr 2026
13 points (100.0% liked)

Nowhere Else To Share

1069 readers
36 users here now

I didn't know which community to post something in, and so here we are.

Please comment if you know a more appropriate community for a post.

Be nice. All instance rules apply.

Rules:

  • Be respectful. Everyone should feel welcome here.
  • No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia.
  • No Ads / Spamming.
  • No pornography.

Règles :

  • Soyez respectueux. Tout le monde doit se sentir le bienvenu ici.
  • Pas de bigoterie - y compris le racisme, le sexisme, le capacitisme, l’homophobie, la transphobie ou la xénophobie.
  • Pas de publicités / Pas de spam.
  • Pas de pornographie.

founded 2 years ago
MODERATORS
can@sh.itjust.works
can@lemmy.ca
ModeratorCan@lemmy.world
13
"focus stealing" ought to be a solved problem by now... (lemmy.ca)
submitted 3 weeks ago by xia@lemmy.ca to c/nowhereelsetoshare@sh.itjust.works
9 comments fedilink hide all child comments
 

It seems to be, that the rule ought to be:

  • "if the operator's mouse/keyboard event which originally spawned the new window is still the last one generated, then it may grab focus"

In other words, if the user is WAITING on a window to pop up, then it takes focus. But otherwise (such as the user typing in another document) it does NOT take focus.

Of course, in this context, I refer to only key-down and mouse-down events, not passive events like mouse movement.

you are viewing a single comment's thread
view the rest of the comments
[–] lurch@sh.itjust.works 3 points 3 weeks ago

depending on type of window management it can appear above another window under your mouse cursor, in which case it stole the focus. imagine you're about to click a download button and instead a window with a delete prompt appears above the button and you confirm that instead. my point is: focus settings alone don't fix this.