- Have several (focused) windows open on different workspaces. - Make one of them "sticky" (visible on all workspaces) and click on it to give it a focus. - Cycle through all workspaces. - Switch focus to another (non-sticky) window. - Cycle through all workspaces again and observe that the sticky window took focus from all previously focused windows. Although this design isn't unjustified (if we treat the sticky window like any other window), it is extremely annoying in dual-screen setups. My use case typically involves having some windows pinned on a secondary display (for preview, monitoring etc.). If I accidentally click on any of them they start stealing focus from windows on my primary display. Two potential solutions: 1. When switching the workspace, always give the focus to the recently focused window on that workspace (ignore the fact that the currently focused window is pinned). Users (well, I) expect the pinned window to be visible on all workspace, not to have focus on all workspaces. 2. (workaround for multi-screens) - keep separate lists of recently focused windows on each workspace for each screen and use focus follow mouse to switch focus between screens (see bug #8866).
If a window is visible on all workspaces, and that window has focus, it's necessarily the last focused window on all workspaces (as the user is unable to focus a window from another workspace). a). Once a "sticky" window receives focus, it remains focused when changing workspaces, that's normal and expected. b). If focus is set to another non-sticky window, and the user switches to another workspace, it's the most recently used window from that new workspace which is focused, not the sticky window. Again, that's expected. c). If, when switching workspace, all that remains is a sticky window, then focus will be set to that window, which is expected. Once a sticky window receives focus, it remains focus on workspace change, that case a). I have not seen any deviation from this behaviour in my tests, so either I don't understand what your bug description/use case, or else you see a bug that I cannot reproduce.
Hi Olivier, As we discussed it on IRC, my bug description was indeed too simplistic (limited to the case (a) only). Regarding the points you have raised: a) It is one design choice but I disagree this is a "normal and expected" behaviour by the users. I, and likely many other users (see bug #8865), would prefer if the focus went to the most recently used window on that workspace. But I agree this is a matter of preference, not a bug. Perhaps this choice could be made based on the existing option "Cycle through windows on all workspaces". If it is off, users likely assume the workspaces to be isolated from each other. b) This is where the actual bug is. In some cases (not reliably, it doesn't occur immediately after making a window sticky) I can reproduce it with these steps: - have non-sticky windows on all workspaces focused, - on one of the workspaces focus the sticky window, then focus the non-sticky window again, - cycle through workspaces, -> all non-sticky windows have lost focus to the sticky one. I can also reproduce it reliably with these steps: - have non-sticky windows on all workspaces focused, - on one of the workspaces focus the sticky window, - switch to another workspace and back (sticky window maintains focus), - focus the non-sticky window again, - cycle through workspaces, -> all non-sticky windows have lost focus to the sticky one. In practice, the sticky window *will* end up stealing focus from other windows, even if in non-obvious manner and not immediately. c) I agree the sticky window should maintain focus if it is the only window on a target workspace.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/80. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev