Steps to reproduce: 1. Turn of Raise on Click in the Xfce 4 Settings Manager's Window Manager group (under Focus tab), and Turn on Compositor (Window Manager Tweaks group). 2. Open a Mousepad. 3. Open a Thunar. 4. Open a Calculator. 5. Position these three windows so Mousepad is at bottom, Thunar above that, and Calculator on top of them all. If they all overlap slightly, it's even better demo of bug. 6. Click Calculator title bar to ensure it has focus and is on top. 7. Click *inside* Thunar to give focus, as if you're working on it, but do not bring to top. 8. Click *inside* Mousepad to give focus, as if you're working on it, but do not bring to top. 9. Do some writing in Mousepad. 10. In Mousepad: Ctrl-f (or menu Search-->Find...). 11. Press "Esc" key, or Cancel, or even correctly find some text. BUG: Calculator now has the focus! I would expect Mousepad to have focus since that was what I was working with. Also note: Bring Calc to top, click inside Thunar, click inside Mousepad. Exit Mousepad. BUG: Calculator has focus. Also note: Same behaviors if windows do not overlap. == more info on workflow/context below == With the compositor running, and with Raise on click turned off: I have two windows I'm working with (e.g. two Thunar windows or one term and one GEdit). I use Ctrl-o to open a file in Gedit to work on. When the file-open dialog goes away, focus is set to the terminal, not the one I was last at (Gedit). That is, it seems that the Window focus order is missing the last-focused window in certain circumstances when Raise on click is off. It seems that clicking *within* a window to change focus does not add that new window to top of the last-focused list. So, when a new window closes, an older window gets the focus instead of the true last one. With Raise-on-click off, I want focus returned to the last one that had focus, *even if that last one was not on top* (i.e. below the others in z-order).
I just tested this same issue with the compositor OFF. Same behavior. I took the reference to compositor out of the issue description.
This last-focused issue probably also applies to the question of which window should get focus when the one you are working on is sent to back.
This is on purpose actually. The previous focused window may have been entirely covered by another window (for example either Thunar or the calculator in your example) so sending focus back to a non-visible window is a usability issue imho. Older versions of xfwm4 used to raise the parent window when a modal dialog was closed to avoid this, but it was causing some other problems with some apps (kde apps iirc, but it's from memory). Beside, some people did not want the stacking to be changed so it was seen as a bug as well. So to keep things simple, I chose to send focus back to the top most focusable window (except in focus-follow-mouse mode in which case it's sent to the window under the pointer if any, or the top most otherwise). If you check in bugzilla you'll find tons of bugs regarding focus translations, the current model works in most case and is simple enough so I would rather not change it. I understand it's not optimal in the particular case of click-raise = false but I see this as some sort of a corner case.
(In reply to comment #3) > The previous focused window may have been entirely covered by another window > (for example either Thunar or the calculator in your example) so sending focus > back to a non-visible window is a usability issue imho. I respectfully disagree. I think it is *highly* unlikely that the previously-focused window would be entirely covered by another window. Partially-covered, yes, but entirely covered, unlikely. In the case of modal windows, when the modal window closes, the previous window (it's parent) was the one that you were working on (e.g. mousepad). If you were working on it, then a workable/viewable part of the parent was probably visible. That is, people don't work with fully-obscured, but fucused windows. So, sending focus back to the previously-focused window, in this case, would be the one that would never actually be obscured. > > Older versions of xfwm4 used to raise the parent window when a modal dialog was > closed to avoid this, but it was causing some other problems with some apps > (kde apps iirc, but it's from memory). Beside, some people did not want the > stacking to be changed so it was seen as a bug as well. I don't see how returning focus to a parent window adjusts stacking. In fact, I don't see how focus adjusts stacking at all. I don't know about kde apps or other things, but perhaps those problems are long gone now that they've likely been updated or replaced with newer software. > > So to keep things simple, I chose to send focus back to the top most focusable > window (except in focus-follow-mouse mode in which case it's sent to the window > under the pointer if any, or the top most otherwise). I suggest going with setFocus(parent(window-that-closed)). However, I suggest at least considering this hybrid proposal that might help me with this issue in my most-used confusing case: OnWindowClose() { w_parent = parent of window just closed. w_top = top-most focusable window. IF (w_parent is partially-or-fully covered by any other windows except the xfce-panel) { THEN setFocus(w_top). } ELSE { THEN setFocus(w_parent) } } This way, when I'm using a mousepad window that is completely uncovered, and I use Ctrl+F to find a word or Ctrl+O to open a file, then focus would always return to mousepad. It is this scenario that bugs me most, actually. I like having raise-on-click, but even when I'm using windows that are side-by-side, after a modal dialog closes for one, then the other window gets focus -- totally unexpected because the z-order of those side-by-side windows is arbitrary! > > If you check in bugzilla you'll find tons of bugs regarding focus translations, > the current model works in most case and is simple enough so I would rather not > change it. > > I understand it's not optimal in the particular case of click-raise = false but > I see this as some sort of a corner case. Thanks for understanding my use case. I really appreciate click-raise=false. Indeed, I switched to Xfce because it better supported this than Gnome (yet it is simpler than kde). It seems to me that applications that break under raise-on-click=false have their own issues. They should be able to handle it.
-- 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/46. 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