Created attachment 154940 [details]
Screencast via OBS

FWIW, ksnip works, but only if "Force Generic Wayland (xdg-desktop-portal) Screenshots" is set.

I was running into this issue as well on Arch Linux, so I tried downgrading spectacle to 22.08.3, which made it work, and then I upgraded it back to 22.12.0, and it still worked after that.

Prior to my attempting the downgrade I already tried rebooting to see if it would fix the issue (which did not work), so no clue if this was just a fluke or what.

I cannot confirm Prajna Sariputra's findings. Downgrading Spectacle does not fix the problem for me, nor does upgrading back.

IMO, the points I mentioned are evidence that some KDE component might be broken, esp. since ksnip's Plasma Wayland backend fails but the generic XDG one still works.

After rebooting the issue did indeed come back with Spectacle, and this time downgrading it didn't change anything, but after upgrading it back to the latest version it started working again, so no clue what is happening behind the scenes there.

I can reproduce the issue with ksnip consistently even when Spectacle is working fine though.

The problem persists in spite of some KDE updates. I wonder if I'm the only one experiencing this on Fedora 37?
Anyway, I'd be glad if something could be done; I use screenshots a lot and ksnip is really inconvenient compared to spectacle.
(Or if anyone can recommend a better XDG-based screenshot tool than ksnip, that would be welcome too.)

> Console output says 'Screenshot request failed: "The process is not authorized to take a screenshot"'.

Is Spectacle being run from the same prefix as kwin_wayland? If you're using /usr/bin/kwin_wayland, you have to use /usr/bin/spectacle. I don't know exactly why that is, but it's either a wayland thing or a kwin thing and I know it's intentional. I think it's related to security, but it is annoying if you are building software from source.

*** Bug 462488 has been marked as a duplicate of this bug. ***

*** Bug 462509 has been marked as a duplicate of this bug. ***

(In reply to Noah Davis from comment #7)
> Is Spectacle being run from the same prefix as kwin_wayland? If you're using
> /usr/bin/kwin_wayland, you have to use /usr/bin/spectacle.
They're both from /usr/bin (verified using command paths shown in process explorer).

Since this is a permission error, I wonder if it is possible to somehow inspect/modify which applications/binaries have screenshot permission?

I still don't have a way to reproduce this, even with version 22.12 (the version this bug was filed for), but it seems like you're not the only one who has encountered this issue before. Spectacle had a major UI rewrite for 23.04 with some backend changes, but the bug might still exist for 23.04, so I'm leaving it open.

Is there any way how I could help you reproduce/analyse this?

FWIW, I also installed the kdeapps flatpak beta of spectacle, but its GUI doesn't even show up. Is this expected?
The command line output basically is
```
$ flatpak run org.kde.spectacle --version
libEGL warning: wayland-egl: could not open /dev/dri/renderD128 (No such file or directory)
spectacle 23.03.70

$ flatpak run org.kde.spectacle
libEGL warning: wayland-egl: could not open /dev/dri/renderD128 (No such file or directory)
Error querying plasma version "org.freedesktop.DBus.Error.ServiceUnknown" "org.freedesktop.DBus.Error.ServiceUnknown" [geisserml: further occurrences hidden]
Error calling KWin DBus interface: "org.kde.kwin.Screenshot.Error.NoAuthorized" "The process is not authorized to take a screenshot"
```

> Is Spectacle being run from the same prefix as kwin_wayland? If you're using /usr/bin/kwin_wayland, you have to use /usr/bin/spectacle.

It appears this applies not only to the location of the binary itself but also the path in the `Exec` field of the desktop file. I can reproduce the issue (as in the same behaviour exhibited by Spectacle) if I copy the `/usr/share/applications/org.kde.spectacle.desktop` file to `~/.local/share/applications` and changing the `Exec` field to just say `spectacle`, and if I change that back to `/usr/bin/spectacle` then Spectacle starts working again.

The weird part about it though is that the original desktop file already had the correct contents for the `Exec` line, and there was nothing Spectacle related in my `~/.local/share/applications` folder, so if I had to guess the reason I encountered the issue back in comment 3 and why the downgrade of Spectacle back then made the problem go away is that the desktop file database was corrupt somehow and the package downgrade also refreshed that database (there is a step saying "Updating the desktop file MIME type cache...", which under the hood runs the `update-desktop-database` command). Spectacle did start exhibiting the issue again today, and this time reinstalling Spectacle made the issue go away, which I think supports my theory of the desktop file database being corrupt in my case causing issues, and is also why I came back to this bug report.

Also, through this whole period (of Spectacle breaking, then fixing itself, breaking again and fixing itself again for me) Ksnip didn't work the entire time unless using the portal method, but the difference appears to be that Ksnip's desktop file only had `ksnip` in its `Exec` field, applying the same change as I did with Spectacle for testing (changing that `Exec` field to say `/usr/bin/ksnip`) also made Ksnip start working again.


TL;DR: Make sure there is nothing Spectacle related in `~/.local/share/applications` and run `update-desktop-database` in a terminal (install the `desktop-file-utils` package if you don't have that command), might fix the issue with Spectacle.

Again, none of what Prajna Sariputra wrote applies to my case. I don't have a spectacle entry in `~/.local/share/applications`, and `/usr/share/applications/org.kde.spectacle.desktop` shows `Exec=/usr/bin/spectacle`. Logically, running `update-desktop-database` does not change the situation for me.

Apart from that, I never had a custom build of spectacle installed, but I guess Prajna Sariputra might have. From what you wrote, I suppose your `spectacle` does not resolve to `/usr/bin/spectacle`, but something different, like `/usr/local/bin/spectacle` - can you check the return of `which spectacle` to confirm?

> Is there any way how I could help you reproduce/analyse this?

I can't think of anything specific since I have no idea where to start. While the location of the desktop file potentially being an issue is interesting and should be fixed, it sounds it's not your specific problem.

Trying to take a screenshot via qdbus fails as well:
```
$ qdbus-qt5 org.kde.KWin.ScreenShot2 /Screenshot org.kde.kwin.Screenshot.screenshotFullscreen
Error: org.kde.kwin.Screenshot.Error.NoAuthorized
The process is not authorized to take a screenshot
```
(I assembled the command by completion proposals, so not fully sure if it's actually valid, but it seems to run into the same permission error...)

Created attachment 155417 [details]
Spectacle being fixed by messing with the desktop file???

Okay, the issue is back again, while running `update-desktop-database` didn't fix it this time copying the `/usr/share/applications/org.kde.spectacle.desktop` file to `~/.local/share/applications` did it, and I also managed to get a screen recording of Spectacle being broken and then it working again afterwards.

Also, I've never even compiled Spectacle from source, let alone installed it in a different prefix.

Crazy. It looks like your bug might be something fundamentally different compared to mine?
Are you sure you're drawing the right logical connections and that this is not just coincidence? I see your screencast, but I still can't logically understand how the desktop file should change anything, if you run spectacle from the command line - aren't desktop files only relevant for launching apps from a graphical interface ... ?

So far I've had the bug appear 4 times (it happened again after my last comment), and all 4 times it fixed itself by some manner of my tinkering just like in that recording (and all of them end up doing something to the desktop files either directly or indirectly like reinstalling Spectacle), if it weren't so baffling I wouldn't have kept coming back here.

Although according to the discussion in this Ksnip issue report (https://github.com/ksnip/ksnip/issues/727#issuecomment-935591743) it appears that KWin does care about the .desktop files as far as checking if a process is allowed to use the private screenshot API, which is why I don't think it's implausible for it to be at least tangentially related.

Thanks for linking the ksnip thread, that's interesting...
I see there is an entry `X-KDE-DBUS-Restricted-Interfaces=org.kde.kwin.Screenshot,org.kde.KWin.ScreenShot2` in the .desktop file, but I can't believe that's taken for a permission check. That would be inherently unsafe, especially if local desktop files were taken into account, wouldn't it?

Funnily enough, my spectacle now randomly works again. Let's see if it stays that way.

*** Bug 465198 has been marked as a duplicate of this bug. ***

*** Bug 465147 has been marked as a duplicate of this bug. ***

For me, the problem is gone. Should we close this bug, or keep it open for others to provide further feedback?

In my case Spectacle still switches between working or not whenever it feels like it, sometimes doing the stuff I did earlier like reinstalling Spectacle got it to work, other times it doesn't, to the point where I just gave up and assigned the print screen keyboard shortcut to Flameshot in quiet mode instead of Spectacle.

Still just crashes on Ubuntu 22.04 Wayland

Just uninstalled via apt and attempted to install with snap. Snap couldn't find it.

I reinstalled via apt.

Running the app still reports "Cannot take screen shot"

@drmacro Does it crash, or does it say "Could not take a screenshot", or both?

Crash is the wrong word. It definitely says "Could not take a screenshot"

Starting from the commandline with sudo produces the same error when the Take snapshot button is clicked.

Thanks for clarifying!

I'm marking this as fixed since the original reporter stopped having issues and a new version is out. If someone else has this issue with version 23.04, make a new bug report.