Expected: Normal window minimization Experienced: Window appears to minimize. The area where the window used to be appears unresponsive to the mouse. In reality, mouse and keyboard inputs are going to the invisible minimized window which may become evident later. Reproduction This works with any group of windows, but I am using Konsole windows as a specific example. 1) On an empty desktop, create two Konsole windows. 2) Tab-group these windows. 3) Minimize the grouped window. 4) Right-click where the window used to be. The context menu for Konsole will appear despite Konsole not being visible. 5) Make some typing input. 6) Restore grouped window. Notice typed input went to Konsole. If any two windows A and B are tab-grouped, and A is the visible window when minimized, these errant inputs are captured by A rather than B. Arch package version is 4.10.1-1. No error messages seem to accompany this.
Does this also happen w/o compositing? (Or does the window remain visible then?)
(In reply to comment #1) > Does this also happen w/o compositing? > (Or does the window remain visible then?) After turning off compositing, the difference is that the window does not disappear when minimizing. However the window loses focus and acts minimized when interacting with a Task Manager widget.
Can you please determine the WIds of both tabbed clients (xwininfo) and after "minimizing" the group call xwininfo -id wid_#1 > window_1.info xwininfo -id wid_#2 > window_2.info xprop -id wid_#1 > window_1.props xprop -id wid_#2 > window_2.props and attach those files here? Also (maybe use a kwrite instance next to konsole) which one remains visible? The one that was previously visible or the other one?
Scratch that, sorry. *** This bug has been marked as a duplicate of bug 315956 ***