https://bugs.kde.org/show_bug.cgi?id=360878
--- Comment #4 from r...@alum.mit.edu --- More information: I can reproduce this with focus follows mouse/mouse precedence, with focus stealing prevention anything up to high. It does not happen with extreme focus stealing prevention. It is not specific to focus under mouse. The particular operation I'm doing in LibreOffice is Insert->Names->Manage... . After I edit one of the names and click OK in the Manage Names dialog, the dialog does not immediately pop down. Instead, LibreOffice runs continuously and hard for several minutes, after which the dialog goes away (that's not a bug in LibreOffice per se; the spreadsheet is just ridiculously big and complex). That is the exact moment at which the window in the other virtual desktop loses focus (as determined by watching the pager in the panel) and it switches to the main LibreOffice window. After that, LibreOffice continues to run for another minute or so before accepting input. By typing on the keyboard and then switching back to the other virtual desktop, I can verify that the keyboard focus has been given to LibreOffice. (Just a gripe, I hate this term "unreasonable focus policies". It's not apparent what's unreasonable about wanting the focus to always remain under the mouse. I know alt-tab and such won't work, but I don't use them and never have. If I have a dozen or more windows up, alt-tab is useless to me because it goes through them in no particular order. I use keyboard accelerators to raise/lower windows, and I can also select them from the panel. I cut my teeth on X9/X10 in the mid 1980's and really like that simple paradigm.) -- You are receiving this mail because: You are watching all bug changes.
