Cannot manipulate the pinned window using i3 shortcuts

[c02y]

Flameshot Version

12.1.0-1

Installation Type

Linux, MacOS, or Windows Package manager (apt, pacman, eopkg, choco, brew, ...)

Operating System type and version

Arch Linux 5.18.9-zen1-1-zen

Description

When I pin a screenshot, the pinned window cannot be manipulated by i3, such as

1. I cannot move the pinned window to another workspace(pinned window will follow focus, and move command will move other window in the workspace)
2. I cannot quit/close the pinned window using i3 quit shortcut
3. I cannot move or resize the pinned window using i3 move/resize command
4. I cannot toggle the pinned window between floating window and tiling window

BTW:

1. When I try to move the pinned window to another workspace, the window and all the pinned windows will be moved into the workspace at the same time, the pinned windows will follow the focus to another workspace, but it is not controlled by i3 shortcut.
2. I can move the pinned window using mouse or even activate the context menu of right click.

Steps to reproduce

1. run flameshot gui
2. take a screenshot
3. pin it
4. try some i3 shortcuts such as move it to another workspace or move its place or resize

Screenshots or screen recordings

System Information

1. Arch Linux 5.18.9-zen1-1-zen
2. Single external monitor enabled, laptop monitor disabled
3. i3 v4.20.1-2
4. Xorg

[mmahmoudian]

It has been a while since I've worked with i3, but I'm almost certain that this is an issue of your config and has nothing to do with Flameshot. Here is also a clean install VM of Manjaro i3 that I just did sudo pamac install flameshot and then the rest is in the video:

Peek.2022-07-07.17-42.mp4

Also, logically how your computer deals with window has almost nothing to do with the application but rather your window manager.

I'll close this for now. If you managed to reproduce this in a clean VM, please reopen the issue. Without reproducing an issue, it is very hard (if not impossible) to track it down and fix it.

[c02y]

That is weird, I tried it in fresh new Arch Linux and completely new i3 config, it is the same, pinned window cannot be manipulated by i3 shortcuts.

[c02y]

I tried it in Manjaro+i3, all the latest versions, the same

[mmahmoudian]

I tried it in Manjaro+i3, all the latest versions, the same

This is weird! When I do floating I can do all you want

Peek.2022-07-08.12-35.mp4

This is the XZ compressed of my VM. give it a try (perhaps using virt-manager):
https://drive.google.com/drive/folders/1eofgT85IyDMngOp8DPDegbUejL-_Jm3b?usp=sharing

Please let me know when you have downloaded it so that I remove the file on my end.

[c02y]

Yeah, I can see that yours is normal, no need to try it again, but mine isn't. Maybe leave it open for a while, perhaps it will be gone somehow or other people have this kind of issue as well.

[gepbird]

I have the same problem on dwm, and I found out this commit caused the issue.

[c02y]

@mmahmoudian May I ask, what is your Flameshot version? I'm using v12.1.0 in all my 3 gifs, and I tried v11.0.0 which is a cache package file I haven't cleaned, it has the same issue.

[mmahmoudian]

@c02y it should be only one version of 12.1.0 on snap which is visible in all the screen recordings the my previous comments, plus in the VM I shared. Perhaps the easiest is to check the videos. I am AFK and writing this from my phone

[fsrzen]

same problem. OS: Arch 5.18.10-arch1-1; wm: i3-gaps; flameshot: v12.1.0

[mmahmoudian]

@c02y @gutyina70 @fsrzen Can any of you suggest a series of steps (preferably in firm of a script) that can install what's needed to reproduce this issue in a clean VM? As I mentioned and shown before it was not reproducible in a VM I created. Unless we cannot reproduce the issue, we cannot start investigating.

@gutyina70 thanks for your comment, I have asked one of the devs to look into it and see if he can confirm this on his tilingwm

[c02y]

@c02y @gutyina70 @fsrzen Can any of you suggest a series of steps (preferably in firm of a script) that can install what's needed to reproduce this issue in a clean VM? As I mentioned and shown before it was not reproducible in a VM I created. Unless we cannot reproduce the issue, we cannot start investigating.

@gutyina70 thanks for your comment, I have asked one of the devs to look into it and see if he can confirm this on his tilingwm

The VMs in two gifs I posted earlier are both in VirtualBox not virt-manager.

[mmahmoudian]

The VMs in two gifs I posted earlier are both in VirtualBox not virt-manager.

That is the exact reason that I asked for a script. This way the bugs and issues of the virtual machine software can be avoided.

[c02y]

The VMs in two gifs I posted earlier are both in VirtualBox not virt-manager.

That is the exact reason that I asked for a script. This way the bugs and issues of the virtual machine software can be avoided.

No script, simply install archlinux-i3/manjaro-i3 into VirtualBox and install flameshot package, nothing special.

[mmahmoudian]

simply install archlinux-i3/manjaro-i3 into VirtualBox and install flameshot package, nothing special.

That's the problem. From where I stand, if flameshot works on manjaro-i3 of virtmanager (qemu), but does not work in manjaro-i3 of virtualbox, the issue is not coming from Flameshot. This is why I'm trying to have a method to reproduce this agnostic to any abstraction/virtualization layer effect.

[gepbird]

This bug didn't happen when I tried it on manjaro-i3, my assumption is some package fixes this issue that is installed on manajaro-i3, but not on our machines.
I will be providing instructions for reproducing this on a clean arch with dwm soon.

[gepbird]

To reproduce this issue on arch linux with dwm do the following:

Install arch linux + xorg

Download the newest arch linux iso, run it in a VM

archinstall

Go through the install process, and include xorg

• select a Drive
• in Disk layout choose Wipe all..
• set a Root password
• create a User account with sudo privilages
• in Profile select xorg then VMware / VirtualBox
• in Network configuration select Copy ISO
• Install
• after waiting reboot to existing OS and log in

Install dwm, st and flameshot

sh -c "$(curl -L https://bit.ly/3uD8fHE)"

Reproduce flameshot issue

In dwm, press alt+shift+enter to open a terminal. Since we dont have dbus, run the flameshot daemon with flameshot & and dont kill that terminal. Take a screenshot with flameshot gui and pin it.
When switching to another tag (top left corner numbers), the flameshot pin window is still visible, you can't kill it with alt+shift+c, or move it to another monitor with dwm's keybindings. With this issue a black border around the pin window is also visible.

[mmahmoudian]

I can confirm this issue using /archlinux-2022.07.01-x86_64.iso, instructions that @gutyina70 provided, and sh -c "$(curl -L https://bit.ly/3uD8fHE)" which runs the following script:

# dwm dependencies + flameshot
sudo pacman -Sy libxft libxinerama otf-fira-mono flameshot

# dwm install
curl -o dwm-6.3.tar.gz https://dl.suckless.org/dwm/dwm-6.3.tar.gz
tar xf dwm-6.3.tar.gz
cd dwm-6.3
sudo make install
cd ..

# st install
curl -o st-0.8.5.tar.gz https://dl.suckless.org/st/st-0.8.5.tar.gz
tar xf st-0.8.5.tar.gz
cd st-0.8.5
sudo make install
cd ..

# auto start dwm
echo "exec dwm" > ~/.xinitrc
echo 'if [ -z "${DISPLAY}" ]; then exec startx; fi' > ~/.bashrc
startx

@gutyina70 thank you for writing those keybindings those the the first thing I used to change when ricing my DWM back in the day and they never got into my muscle memory.

[diogotcorreia]

I have the same problem on dwm, and I found out this commit caused the issue.

Can confirm this is also happening to me on DWM.
The floating screenshot window now appears on all tags (this is by far the most annoying part) and can't be manipulated with DWM shortcuts (closing it, focusing it, moving to a tag, etc)

[mmahmoudian]

I think this is related to the fact that the pins are not recognized as "real" windows. For instance I just found out that in KDE one cannot switch to a pinned screenshot with Alttab

perhaps it is the same exact reason that i3 does not consider it as something that can be moved simply because it cannot get "focused" in a way.

[mmahmoudian]

@AndreaMarangoni Considering that your recent contributions were around the pin, you might have a fresh memory and an idea on what can be the potential cause of this.

[87elijah87]

In the current version (12.1.0) I can't manipulate pinned windows either. In version 11.0, the control works.

[g-h-97]

@mmahmoudian the issue is consistent across multiple WMs, I'm using dwm here and can't manipulate the pinned window even in floating mode, it's as if it's completely invisible/non-existent to the WM for some reason.

Got some details using xprop, it seems that the pinned window explicitly specifies focus at line 68 & 74. Here are the xporp generated file for flameshot, virt-manager & st respectively:
fl_xprop.txt, vm_xprop.txt & st_xprop.txt

[mmahmoudian]

@g-h-97 thanks for the info and investigation. I have also previously confirmed this on DWM, and another time on KDE X11.

Let's see what other devs think

[87elijah87]

I wrote a little higher, though I didn’t specify one detail. If I now put the previous version, then I get the opportunity to manage windows. If I install a new version on the same computer with the same environment, it is impossible to manage windows.
Operating System: Debian GNU/Linux (sid) KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.4 Kernel Version: 5.18.0-4-amd64 (64-bit) Graphics Platform: X11

[toofar]

I realize that the X11BypassWindowManagerHint flag was added to solve an issue but it would be nice if it was a configuration option at least (to make pinned windows "normal" windows or not, although Qt also has a couple of different concepts of window types, like popup and dialog). It looks like that flag has been added and removed in the past fwiw so it seems it affects a few different workflows.
In my case I would like to be able to minimize and remove the "on top" flag of pinned windows sometimes. Usually when I'm multi tasking (aka getting distracted) and have something pinned for reference that I'll get back to in a while.

A workaround, now that we can saved pinned windows, is to save the pin to a file and open it in feh, or some other minimal image viewer, when I realize I want one to hang around long enough to be treated specially. Or (on X11) copy to clipboard and xclip -selection clipboard -o -t image/png | display -

[toofar]

Seems another workaround you can do to get these pinned windows back under window manager control is to use xdotool to remove the override-redirect property. For example with xdotool selectwindow set_window --overrideredirect 0 windowunmap --sync windowmap --sync (from https://unix.stackexchange.com/questions/669224/how-to-set-the-override-redirect-flag-on-existing-window/680848#680848)

[rudyon]

same problem on bspwm