-
Notifications
You must be signed in to change notification settings - Fork 89
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
[Linux, FlatPak] Permissions need workaround with timeout and helper window #320
Comments
I noticed that behavior for NormCap v0.3.14+, after my Manjaro Linux received the new Gnome version. First ideas about possible causes:
I think it might be a good idea to wait a 1-2 weeks to see, if something upstream is broken. If you experience the same issue, please leave a comment with the Linux distribution and Desktop Environment you are running! 🕵️ |
Same here, Fedora 37, GNOME 43.1. |
Same issue here on KDE Plasma 5.26.4 with Wayland Flatpak, AppImage on Arch Linux |
A month later, I still have this issue on a fully updated Arch. I start looking into it, now... Stay tuned! |
Something I discovered: It seems like other applications have the same issue. E.g. the Flatpak version of the screenshot tool org.flameshot.Flameshot hangs, too, while the native version is working flawless for me. Can anyone with the same issue confirm this? |
Might be related to flameshot-org/flameshot#2880, as flameshot also uses the xdg-portal for taking screenshots. |
Update: I found the underlying issue, and I am working on a fix/workaround right now! Why does NormCap hang?The source problem is, that the "permission for screenshot"-dialog, which asks the user to give NormCap permission to access org.freedesktop.portal.Screenshot doesn't show @up. This leaves NormCap waiting for a response with the screenshot URI, which will never come because NormCap doesn't (yet) have permission to receive it. Why does the permission dialog doesn't show up to give the user the possibility to provide the permission?That was really hard to find out: Two requirements are necessary for the permission dialog to show up:
In a test, I was able to confirm, that fulfilling those two requirements will lead to the "permission for screenshot"-dialog appearing. Luckily, those two requirements are only necessary for the initial first request! After the permissions got granted once, it's possible to again request screenshots with How will the solution/workaround look like?Current idea: I understand that this will not be a perfect solution from UX point of view, but it's my best idea right now and at least should make it usable again. |
While I'm still in to process of releasing the workaround, I opened an issue @ xdg-desktop-portal to (hopefully) clarify the underlying issue: flatpak/xdg-desktop-portal#950 |
The main issue should be fixed with NormCap v0.4.0. But the "solution" (as outlined above) is more like a workaround for missing functionality upstream in xdg-portal. I am going to leave this issue open as a reminder to look into this issue again, once there is some movement in xdg-desktop-portal. |
Hello!
Guess: Flatpak (xdg-desktop-portal) has an own timeout and it is violated? |
Hi @flaphoschi, Thanks for you report! Could you please try to run NormCap in Terminal via flatpak run --command=normcap com.github.dynobo.normcap -v debug and share the complete debug log output? That would help me to diagnose the issue and, most importantly, it would tell me if the recently added workaround is applied at all. |
Hi! I installed NormCap again on another laptop with Archlinux: First start from GNOME-Shell:
To my surprise several seconds later a permission for screenshots was requests. I granted the permission! Also I recognized a small window in the background:
So I assumed NormCap is useable after the next start but nothing happened and I saw this in the logs:
Withing So I've done what you posted and used
Already running? Yep. I found it in the process list and terminated it.
Now it works. |
Thank you for sharing your detailed investigation, @flaphoschi! That gave me some new insights!
That is exactly, what NormCap is trying to do. But unfortunately, there is no way to retrieve/detect a missing permission directly, as the portal doesn't send any error when a screenshot is requested with missing permissions, it just doesn't send the response. The (quite dirty) workaround that is implemented in NormCap works like this:
A simple implementation of this idea would be to show this information in the already implemented intermediate window ( |
System:
Variables:
Exception:
Traceback:
The text was updated successfully, but these errors were encountered: