-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pass XDG_ACTIVATION_TOKEN to apps launched via launch_app_env
#3703
base: main
Are you sure you want to change the base?
Pass XDG_ACTIVATION_TOKEN to apps launched via launch_app_env
#3703
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Drilling into the frontend implementation from the Server abstraction is placing logic in the wrong place, fragile when that implementation changes, and probably won't work.
We first need to break out the token issue & validation logic from xdg-activation so that it can meet the new requirements. (With this scenario there is no "requester" to check still has focus)
src/server/server.cpp
Outdated
@@ -16,6 +16,7 @@ | |||
|
|||
#include "mir/server.h" | |||
|
|||
#include "frontend_wayland/xdg_activation_v1.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a wrong approach.
We shouldn't be exposing the whole (or, probably, any) of xdg-activation to the server code:
- it is pointless to "pretend" to be a client requesting a token, as the pretend client will not have focus when the token is invoked;
- this code shouldn't care when xdg-activation-v2 or xdg-activation (stable) comes along
A better approach would be to have a token issue/validation API used by both the launch code and the activation protocol
src/server/server.cpp
Outdated
{ | ||
if (auto const config = self->server_config) | ||
{ | ||
return config->the_token_authority()->issue_token({}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this is better or I should add an overload with no parameters
852ccf5
to
6994bc1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a better architecture. But I've not yet looked closely enough to decide how tokens supplied via launch_app_env()
will be handled by xdg-activation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Broadly, I think the TokenAuthority
is kinda half way there. It's not actually an authority - code can't use it to check if a Token
is valid, and that's tracked separately by XdgActivationV1
. This is also why there's spooky action-at-a-distance in XdgActivationV1::invalidate_*()
- you're maintaining a second list of valid tokens, mutating XdgActivationV1::pending_tokens
by calling token_authority->revoke_token(...)
.
I think this would be simpler if:
a) The TokenAuthority
was the... authority for whether a token was valid or not, and
b) Token
was treated more as an opaque... token, rather than immediately decaying into a std::string
and all the interfaces taking that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's cleaner. On further thought, I'm not sure we sensibly can decouple XdgActivation
and the TokenAuthority
further.
Closes #2586. Adds a new constructor to `FloatingWindowManagerPolicy` to control focus stealing prevention. This in a nutshell stops new windows from being focused and raised. When used with xdg-activation-v1, this improves security as external actors can't just steal focus by opening a new window (in addition to the niceties xdg-activation-v1 adds to usability). TODO: - [ ] ~Fix window offsetting. This is built off the position of the focused window, so all windows after the second one open in the same (x,y) position.~ Split off to #3695 - [ ] ~Fix windows closing in the order of opening instead of front to back. see #3693 (comment) Moved to #3694 - [ ] ~Make sure Xwayland applications work properly. My focus has been on Wayland applications so far.~ Xwayland doesn't seem to support xdg-activation at the moment? - [x] Alt + tab predictably broken :/ Have to focus other applications before they work with alt + tab - [x] Decorations are not pushed behind the focused window - [ ] ~Need some way to focus applications launched via Mir (Ctrl-Alt+t/T for example)~ Will be in its own PR (#3703)
TIL that github's conflict editor merges (there's probably a rebase option that I missed) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/usr/bin/ld: unable to find version dependency `MIR_SERVER_INTERNAL_2.19'
/usr/bin/ld: duplicate version tag `MIR_SERVER_INTERNAL_2.20'
collect2: error: ld returned 1 exit status
src/server/symbols.map is ill formed
(With the symbols.map fixed) From Gnome:
Expect: |
a96594e
to
1d6a14f
Compare
Hopefully both issues should be fixed now (facepalm). I'm not very sure about the symbol stuff. I should really spend some time to understand it I recommend testing with firefox and kgx. gnome-terminal doesn't seem to request activation. Edit: To save you some frustration, here's a list of apps that request activation and others that don't: Applications that request activation:
Applications that DO NOT request activation:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is the usecase the PR is intended to address:
From Gnome:
1. `miral-app --focus-stealing-prevention true` 2. `Ctrl-Alt-X` to launch `xterm` 3. `Ctrl-Alt-Shift-T` to launch `gnome-terminal`
Expect:
gnome-terminal
gets focus and raised
Actual:xterm
remains on top with focus
Same with:
miral-app --focus-stealing-prevention true --shell-terminal-emulator=xfce4-terminal
miral-app --focus-stealing-prevention true --shell-terminal-emulator=qterminal
So it isn't just gnome-terminal being weird
gnome terminal does request activation:
But that's not the token in |
That's very weird, it doesn't seem to do so when launched via miral-terminal. But then again, gnome-terminal has been a massive headache so far
I have no idea why gnome-terminal is trying to doxx you, I'm not even sure how it put that as the activation token. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpicking
Also
|
7a7a004
to
ae68e02
Compare
It now keeps track of the active session and prevents unfocused applications from requesting tokens
Ordered includes and made pointers const
Refactored the parameters of `launch_app_env` to use `std::optional` instead of `mir::optional_value`
ae68e02
to
d63b6e3
Compare
This fixes terminals failing to activate themselves due to the key listener immediately revoking their token in response to the terminal launch shortcut being pressed.
This fixes terminals failing to activate themselves due to the key listener immediately revoking their token in response to the terminal launch shortcut being pressed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Behaves a bit better now. :)
Remove log statements to not flood logs Return a proper bogus UUID to prevent clients from knowing which tokens are valid and which are not
No description provided.