[Q]: Focus stealing prevention feature

[GHNewbiee]

Does Miracle-WM provide prevention against stealing of a window focus? Tia

[mattkae]

Hiya @GHNewbiee. What would be the feature here? As far as I understand it, I think it would be:

1. Window A is focused
2. Another Window B opens and requests focus
3. Window A should keep focus if the compositor is set to do so

Is that correct?

[GHNewbiee]

@mattkae Thanks for your response. Just to be more precise:

1. Window A is chosen and, hence, it gets focused
2. To add, that any window requiring "attention" eg password, etc, it merely behaves in different manner eg flashing (?)
3. That's very correct!

[GHNewbiee]

To add in 2) Window requiring "attention" should not lock the focus on itself. That's why it has to behave in a different manner if possible.

[mattkae]

Understood now! Right now, the behavior is that any window that gets brought up gains focus, but we could just as easily provide an option in the config to disable that behavior.

[GHNewbiee]

@mattkae

What about the behavior of a window requiring attention, will it

• give a kind of "signal", or
• lock the focus to itself, or
• be just sent back like a simple/common window?

[mattkae]

• The signal idea would be nice if it weren't for multiple workspaces. If a window required attention on another workspace, then the only way to handle that would be to navigate to that workspace. That being said, we could also use inotify or something and say "Window X on workspace 3 wants your attention"
• What do you mean by this?
• The third option would be the easiest, and then it's up to the user to navigate to it. Although it certainly feels the least "urgent"

[GHNewbiee]

• I am not sure how practical opening apps/wins in different workspaces at the same time is? I have never had a necessity to do that in my whole life. In addition, changing workspace and clicking to open an app/win takes some time. If you feel that using inotify worths the pain / additional work then it's ok. In addition, the project will provide a unique feature!
• There is case that a window locks the focus to itself. In that case you cannot move to any other window unless you close the locked one first.
• That's correct.

[mattkae]

• Yeah maybe that can't happen now that I think of it. I was thinking that an app would spuriously open a window in another workspace, but it would be in the current workspace always. This is actually a void point :+1:
• Ah and is this requested by the client? Is this an X only thing or is there a Wayland protocol that requests this behavior?

[GHNewbiee]

Ah and is this requested by the client? Is this an X only thing or is there a Wayland protocol that requests this behavior?

I get this while trying to open Github Desktop. An "Unlock Login Keyring" window appears which locks the operation. I have to unlock by entering the password first before continue working, although I opened it last .

I log in by means of fingerprint.

I still use X. I do not know the process of that .

See photo attached.

[GHNewbiee]

To summerize:

1. A window may need:

   • "attention", or
   • not (standard/normal window)

2. The focus state of a normal window may be:

   • usual , each new window gets focused
   • retained , (last) chosen window retains focus

3. The focus state of a window that requires "attention" may be:

   • usual, as above
   • retained, as above
   • locking , first DE gets locked, next a kind of attention has to be given and last DE gets unlocked
   • informative, eg window frame becomes red and/or icon in task bar/panel flashing or its frame becomes red, too. Note: informative could be used in conjunction with all three states (usual, retained and locking)

Is there other option ?

[GHNewbiee]

Do X and Wayland protocols distinguish normal windows from windows requiring "attention"?

If not, could a kind of existing flag/option to be used instead of?

[mattkae]

That is a very good question. I know that X11 had an "urgent" hint for this use case (see: https://notes.secretsauce.net/notes/2014/03/19_x11-urgency-hint-and-notifications.html). I am tracing the Wayland form of this now. It looks like the following happened:

• https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/9 tried to introduce urgency but was rejected in favor of https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/50
• This is the protocol now https://wayland.app/protocols/xdg-activation-v1#xdg_activation_v1:request:activate that is meant to handle this use case

Mir doesn't support that protocol unfortunately. However, this protocol in theory passes focus from one surface to another (although, it says nothing about the urgency of the newly focused surface, but it is implied that it is "very" urgent)