Is there any way to fix this via a workaround please?

In comparison, here is how Ubuntu captures Windows by default (using ALT+PRTSCR):

In other words, it seems the same dimensions, but it automatically sets the border pixels to transparent.

This may be doable by capturing the active window dimensions, or some other programming logic.

Is this Wayland or X11?

I don't think that there is a workaround. We take this kind of screenshot by asking the DE what the active window is and what the dimensions of the active window are. The DE provides basically Position, Width and Height of the active window. We don't know what part of those belongs to the window and what is just shadow for example. Then we take a screenshot of that provided region.

We could have a look if there is a way to explicitly ask for only the window without shadow. If we cannot ask something like this via the X11 interface, then there is probably not much we can do.

Ubuntu Mate 20.04-1
Hi was playing around and it seems it might not always be caused by shadows. I disabled and it still shows up.
Seem to remember reading somewhere shadows were around 11px.
Avidemux and Untitled show the border but Pluma Preferences looks fine even though on screen it had shadow. Took Untitled.jpg and cropped as in Untitled Cropped Method.jpg. (BTW it was easier for me to just drag the corners of the crop window). 10 px worked there but was not needed on Pluma.jpg. Don't know why but tried with shadows off (Mate) on LibreOffice, KiCad, FreeCad, Inkscape and they show the extra border.
Alternate workaround is to take screenshot with working tool and then open in Ksnip to annotate.
Determined that Gnome Screenshot works in my Mate as described by OP in both cases of shadows on and off. Mate version tool works as per OP with shadows off but shows extra border with shadows on.

Thank you

Fromn inxi -G:

Display: x11 server: X.Org 1.20.8

How about having a look at the default capture source code for Ubuntu and matching the capture approach?

Gnome is the DE, it doesn't have to relay on X11, it probably knows the stuff itself. I known for example that Spectacle under KDE Plasma doesn't speak directly to X11 or Wayland but rather to the kWin Desktop Manager and it provides all the stuff required for the screenshots, even the screenshots itself. We can't do that.

Been looking into this issue and might be problematic to resolve it in a generic way, X11 seems to be unaware of this region so it's not possible for us to detect what that border is and what the actual window . What we could do here is for Gnome always reduce the rect for that size (seems to be a fixed size), you would get in that case only the window without the region around it. Problematic is that Mate has same border thickness around the window, Gnome on the other hand has a lot smaller border at the top but anyhow, we could detect if Gnome or Mate and cut appropriately.

I think I have found a way how to get the width of this region, calling xprop -id <WindowId> returns the _GTK_FRAME_EXTENTS(CARDINAL) value for left, right, top and bottom offset that we just need to subtract from the rect.

Problem will be probably the snap because we need to invoke another application here. @LyzardKing can we just add xprop as one of the required applications to the snapcraft file?

I believe I have found a workaround, it's a bit ugly, using an output from an external program, xprop to find out how much we should crop. My test on Ubuntu 20.10 worked and the window had no border anymore.

@LyzardKing I have added xprop to the snap file, I hope it's not breaking anything: b94a972

Yes, sorry but I just read this today.
It shouldn't be a problem to add xprop to the snap..

EDIT: should we add it to the flatpak as well?

Does flatpak has this limitation that it needs to allow applications that are used, like we had it for snap (curl and ftp so far)?

Would be nice if someone could test the snap with Gnome and eventually the flatpak.

Yes, the flatpak either needs to set explicit access to a binatry on the host system or to add the binary in the package.
It would be better to test it before we change something.

I have made the change already in the code and the snap package, would be nice if you could give it a try. To trigger it you just have to take a screenshot of an active window on Gnome.

It takes a screenshot of something that is under the ksnip window... not of the currently active window..

You have clicked into the active window? Have you tried a small delay, like 1sec?

Ok.. I need to set the delay, otherwise it doesn't work. But I still get the border

The snap in the edge channel isn't updated yet...
I'll rebuild from source anche test that

Yes, it's probably to fast, it takes the active window rect at the moment you trigger the screenshot and that is ksnip.

yes, I imagined as such. Shouldn't there be a 1s delay by default?

the package is not xprop but x11-utils

I'm testing now... I'll open a PR with the necessary changes

The default delay is 200ms which is enough for ksnip to hide but not for a human to click two windows. You could probably get better results by activating any window and then hitting Global Hotkey for active window screenshot.

Regarding the snap build, strange, last build is 1 day ago

Of course, you can't get just that simple application you have to get the whole util package...

yes, from before the change I think.. especially since it would have failed with the current change

I opened a PR but that was the only change necessary

I need to merge it into the 1.8.1 branch, will do it tonight. Thanks for providing the PR.

I have ksnip 1.8.1 (installed via snap, on Ubuntu 20.04.2), yet I still see the borders around active window screenshots. Do I need any additional setup to fix this ?