I’m experiencing a persistent issue with the global shortcuts feature since updating to Gnome 48. Specifically, the global shortcuts setup popup repeatedly appears whenever I launch certain applications, such as Nautilus and Chrome. Regardless of whether I click ‘Add’ or ‘Cancel’ within the popup, it continues to reappear every time these applications are launched.
Detailed Problem Description:
After updating to Gnome 48, the global shortcuts setup popup repeatedly appears.
Clicking ‘Add’ or ‘Cancel’ in the popup does not resolve the issue.
This issue primarily affects the launch of applications like Nautilus and Chrome.
Desired Solution:
I request that the development team address and fix this issue to prevent the recurrent popup.
If a temporary workaround is available, please provide the necessary steps.
You could ask your distributor to include that fix. If you get Chrome directly from Google, the fix will be included in a future release but I don’t know the details of how their release schedule works.
I’m just giving an example. This problem occurs in many things. For example, a gnome extension called wallpaper slideshow is triggered at the same time. I guess the root cause of this problem is: whether it is canceled or added, it has no record of the status, or the recorded status cannot be read by the application, so that every time the application triggers the detection, it will think that I have not set it yet, just like the permissions of Android or browsers. If I don’t agree or refuse, a permission request will pop up every time. This is the root cause, not a problem with a specific application, but a common problem for many applications. I have two separate installations, both Archlinux, and both have the same problem.
I think an improvement would be to save the app ID and settings state as a list in gsettings, or in some file. When an application requests, Gnome verifies whether the user has already added or denied it to decide whether to display it. In this open source environment, you cannot expect third-party developers to fully comply with the specifications, just like browsers and Android do. Even if the application requests again, the request window will not pop up for permissions that have been agreed or denied.
This is not at all elegant nor safe in the longterm, but the binary responsible for the pop-up is called “gnome-control-center-global-shortcuts-provider” and the rest of Gnome functionality doesn’t need it to work.
Locate it within your system and move it to your home folder or any location where you can safely restore it from in case you need it again which you can do by just moving it to the same folder it was in originally.
Keep in mind that any update to gnome or the gnome-keybindings packet will generate a new binary in its originall place. You can just repeat the process in that case.
I also don’t think it’s right from Gnome to put all the blame on app developers and I think that a safe solution for the user side should be provided.
The blame is on Chrome developers, though: they are the ones using the API in the wrong way. Users should complain to Google and to their distributions; GNOME has nothing to do with it, except providing an implementation for the API that Chrome is using.
I disagree with this point of view. Anyone involved in development should know to always treat users as if they are foolish (developers using GNOME’s API should also be considered users in this context). You are not Apple; you cannot enforce rules on developers through strict requirements. Like my examples above, why can browsers restrict APIs? Why can JavaScript alerts be blocked by the user after popping up twice? Why must a click action only occur after user interaction? Why can’t videos with sound autoplay? You cannot guarantee that developers won’t have malicious intent, and while this malice or incorrect usage might not be your direct fault, the resulting poor experience is ultimately passed on to the end user! Unrestricted freedom isn’t true freedom. For me, having this feature you provided is currently worse than not having it at all. I’ve been perfectly comfortable without this so-called global shortcut for many years, and now, because of one application’s mistake, I constantly have to close those annoying windows! What if another developer makes the same mistake someday?
Why do browsers implement various restrictions? Couldn’t they just provide an API and leave it at that, assuming any problems are just the developer’s fault for using it incorrectly? But precisely because it’s impossible to control every developer, the browser itself needs to implement some controls to prevent the end-user experience from deteriorating. I wouldn’t call it a responsibility or an obligation, but rather a gesture of goodwill that shows they care about the users.
I don’t believe adding a capability to the binding popup—similar to how browser or mobile phone permissions, once denied or granted, allow subsequent requests to be automatically ignored—is actually that complicated. This itself is an independent, simple function (referring to the binding popup part, not the actual operational mechanism of the global shortcut). Adding such a check isn’t complex; it’s merely tracking a state. It’s disappointing to have this suggestion rejected.
It’s entirely up to you to disagree with an opinion, but in this very specific case it was a bug in Chrome, and you can’t disagree with a fact. Chrome re-registered all key shortcuts in the global namespace, and that caused the UI to pop up. This happened because the initial implementation of the shortcut portal was developed prior to GNOME providing the global shortcuts portal, and was not tested against GNOME prior to its release.
The issue has been fixed in Chrome, but requires time to propagate; there’s not much GNOME can do about it because GNOME is not a downstream project packaging things up for users: that’s a Linux distribution’s job.
You also seem to confuse the role of GNOME, if you compare it with a web browser.
It’s not just browsers; Android is included too – I develop for both – and similar functionalities exist there. For instance, take the UI for app permission requests on Android: once a permission has been denied or granted by the end-user, if the application requests that same permission again via code, the UI prompt won’t appear again; Android blocks it.
As the provider of the API, the UI, and the entire desktop environment, I don’t see GNOME’s role as different from that of a browser or the Android platform. This is because GNOME controls the UI itself and operates at a higher level relative to individual applications. For Chrome to invoke that shortcut binding window, it requires GNOME’s consent. GNOME inherently has the authority to prevent that window from appearing. Therefore, GNOME shouldn’t be merely passive.
I understand your perspective might be that GNOME just provides functionalities requested by applications, acting simply as a cooperating party. However, in my view, as the entity controlling the entire graphical interface, GNOME should be considered higher-level and possess more authority. Consequently, it shouldn’t just cooperate but should also be able to impose requirements and restrictions.
Like browsers and/or Android, GNOME is a platform. Everything displayed within it should logically be considered downstream from it and needs to adhere to GNOME’s rules.
You’re still confusing what GNOME is or does. GNOME has no leverage to impose. Unlike a web browser, or Android, GNOME does not control the application delivery pipeline, and cannot impose any restriction. GNOME cannot prevent “the user experience” from deteriorating; how can it? Let’s say that GNOME Shell, using some unknown magic, detects that Chrome, or any Chrome-based/Electron-based application, is requesting shortcuts, and does not show any UI; how does that prevent a malignant application from taking advantage of that? How does that work when Chrome/Chromium/Electron gets fixed, since there’s no “user agent” when doing IPC calls to the portal? How does that work with libraries? How does that work when distributions can decide to patch things on their own?
GNOME is a platform, sure; it’s not a platform in the same sense that Android is a platform: application developers are not asking GNOME for permission to distribute their work, and vendors are not asking GNOME for permission to deploy on their hardware.
I understand you’re frustrated about some bug; there are plenty of those around. Your frustration does not make the world work differently.
Of course GNOME has something to do with it. GNOME is the software responsible for showing the message and it can control wether to show it or not independently of what the application requests. It doesn’t matter if the application is poorly made, the user should have control over the message in question in order for them to decide if they want to be bothered by it or not in case the chrome team doesn’t want to solve it. For example, GNOME has functionality to manually silence an applications notifications in case they’re bothered by them, why can’t this be done for global shortcuts.
Just as Efeme04 mentioned, GNOME is the entity ultimately responsible for displaying this window. Similar to other UI functionalities – where you have the authority to implement ‘Do Not Disturb’, block notifications, or collapse them – you likewise have the authority to let the user decide whether or not to display this global shortcut window!
Isn’t gnome-control-center-global-shortcuts-provider GNOME’s own component? Aren’t application requests received through it? Is this ‘magic’?
And what users want is merely something like the notification settings – just the ability to turn it on or off. It’s simply about adding a blacklist/whitelist check within this binary!
Related question… I have 3 chromium-(135)-based browsers installed.
Chromium, Brave, and Edge.
On both Chromium and Brave I was presented with the dialog many times and suspect I may have accidentally clicked the “Add” button, as the dialog has long since stopped appearing for those two browsers.
However, Edge still presents it and I diligently hit “Cancel”
This will not be made, as the global shortcut permission is not a allow-deny permission. That’s about being able to configure shortcuts. That’s the same for the screecast portal where it is about configuring (selecting) video sources.
However, I concur that an app being able to spam portal windows, as seen in the Chromium bug report, does not result in a great user experience. This indeed makes look the system letting apps doing what they want when we talk about system and user control with Wayland and portals. There is the window spam problem with the session restoration of the screencast portal, where some users are expecting to get one window instead of multiple.
Sure, apps not using properly the portal API is a thing, but I think avoiding window spam is something to consider for the global shortcuts portal, in the same way as for the screencast portal.
For avoiding an app making subsequent requests after a canceled request by the user, that’s another story as the app must be able to make those. Even if there was a response like “Do not use global shortcuts”, that will block the app from making the request in case the user changes their mind. And it is preferable to let the app having a request to let the user change that rather than them going opening system settings for that.
In fact, if we follow this line of reasoning, the same applies to permission restrictions. When a user denies a permission, what should happen the next time they want to enable it? Should the application be allowed to show the permission request dialog again? This would lead to some poorly developed applications repeatedly showing pop-ups, resulting in a poor user experience. Therefore, the current design is to only show the prompt once. If the user wants to change their decision later, they must go to the system settings to do so manually. This is a solution validated by many user experience because neither granting permissions nor setting shortcuts are frequent actions.
And in fact, GNOME has already implemented such an interface: under Settings → Apps → <app name> → Permissions, there’s management for notification toggles and Global Shortcuts. However, there’s an issue regarding Chrome. The Chrome requireing shortcuts for Extentions, but there only has shortcuts for the main Chrome application itself in settings.
Actually, this could be further optimized by incorporating all application-registered shortcuts here for unified management. Additionally, an entry point for application shortcuts could also be placed within the Keyboard settings. This would create redundancy, of course, but consider Android’s Settings design – it employs a similar strategy. This allows users to find settings more intuitively, because users don’t necessarily share the same mindset as developers. For example, while a developer might categorize notifications strictly under ‘Notifications’, a user might associate them primarily with sound (the notification tone) and thus look for related options under ‘Sound’ settings.
There is no reason to change the design of a thing just because of an app bug. You should know that an app can do the same, for example, with the screencast portal and the file chooser portal. Imagine an app insisting on you opening a file, but you don’t want to. Do you think it makes sense to disallow the app to request file opening when the user cancels the request?
Palm