Dialogs switch the stack to an incorrect window #712
Comments
|
tl;dr popos is changing window the active window in the stack when it shouldnt - i got automatically switched to the browser here by just triggering a rename dialog in intellij. Oddly PopOS shell switches back to the correct window once I've completed the action so more annoying at this stage than anything else |
|
NAME="Pop!_OS" |
|
Dialogs aren't permitted to tile, so something else is happening. I've been looking into this |
|
Thanks. I've updated the bug description tl;dr - easier to replicate via just opening settings rather than trying to get a rename window going. |
|
Was this fixed by 2a3560a? |
|
Just tried with latest verison, still busted, in stacking mode, opening a dialog like rename variable (shift+f6) switches the stack window |
|
Just to update replication instructions on latest, renaming has become inline in many Jetbrains IDEs, ill choose most popular IntelliJ, so stacking setup with three windows (ff, intellij, terminal), so easiest way now is to shift twice in quick succession (brings up the All tasks selector), and choose the first option for example (Analyse Stack trace or thread dump), pop os gets confused and focuses the nth window in the stack (the terminal) whilst this dialog is showing, and back to nth-1 (the middle - intellij ) after closing.. |
|
To be clear, this is not a problem in i3wm on the same popos distro (and thus same intellij), and seems to only happen in stacking mode |
|
Hello all, I have the same issue. I don't know much about the inner workings here but it looks to me like an off by one index somewhere. It seems to always switch to the last window I have selected, i.e. if I Firefox, Spotify, IntelliJ, if I open Firefox, then IntelliJ, then open a dialog, it shows Firefox, however, if I open Spotify, then IntelliJ, dialogs switch to Spotify. Also, dragging editor windows also causes this, which makes dropping windows extremely hard. |
|
Yes, I initially thought it off by one too, I think it's expecting the dialog to be part of the stack and then it tries to switch to it but that exceeds the number of windows in the stack so either lands on the next one or back at 0 @mmstick would any diagnosis material help on this? a video via dropbox for example? |
|
Could this be related to having _NET_WM_STATE_SKIP_TASKBAR? WM_STATE(WM_STATE): |
|
This is still happening in the latest dev branch, although not as much. activate is getting called in stack.ts, and then usually the first window is getting selected due to Ecs.entity_eq(entity, component.entity) returning true. There are times I can't replicate this though now until I select a different window in stack and then switch back to IntelliJ then it's replicatable again. Will try and do some more exhuastive debugging |
|
1616834689767=== activate called == ist2:false Here how activate is being called... seem to come from focus |
Okay managed to get this solved for my use case, but unsure what other problems I've introduced here by simply commenting out. |
|
Revising src/extensions.ts:L590 This now works and I've reduce the hack to apply to stack only, I'm heavily skeptical that this is the correct fix though, @mmstick any thoughts on further troubleshooting this? |
|
just further ramblings, it seems this can also be solved by wrapping the 'notify::focus-window' handler ~L1670 with a GLib.timeout_add 300ms, as get_focus_window() does not return null after 300ms, perhaps suggesting Swing dialogs are somewhat delayed by coming into focus after whatever event notifies new dialog/window. Interesting.. |
|
300ms delay breaks active hint and management mode |
|
Eek. I wonder if we changed it to fire immediately if there is a focused window, and only if falsey, then schedule a timeout for 300ms to run? 300ms see |
|
I've just upgraded my machine's packages (pop-shell== |
|
I upgraded to Pop OS 21.04 beta & COSMIC. This problem exists and makes window stacking unusable with IntelliJ or other Jetbrains IDEs. @mmstick is there a plan to address this issue? |
|
@lhotari All issues are planned to be addressed, but wanting to fix them doesn't automatically make the solution known. |
|
Is there any way to permanently disable the stacks feature until this gets fixed? IntelliJ is pretty much unusable with this bug. I feel like I've seen the option previously but I can't find it any more. |
@mmstick I really love Pop OS Shell. Pop OS Shell has the best window manager that I have ever used and the stacking and auto-tiling features are incredible. This single bug makes the user experience terrible. The reason is that I use IntelliJ and this bug shows up mainly with IntelliJ (and other Jetbrains IDE products). |
|
The problem might be caused by IntelliJ. I found this blog post: https://makandracards.com/makandra/40343-how-to-fix-rubymine-intellij-find-file-dialog-losing-focus-on-awesome-wm . It suggests enabling |
|
I found a workaround for using IntelliJ. If I change the focus to some other window outside of the stack and then switch the focus back to IntelliJ, the dialogs get focus as expected. The problem with IntelliJ seems to occur when another window such as Gnome Terminal or Chrome has been the previous window as part of the same stack. Switching between multiple IntelliJ windows in the same stack doesn't cause the problem. |
|
Even though the blog post "How to fix: RubyMine / IntelliJ "find file" dialog losing focus on awesome wm" is in different context, I wonder if the details in about using This was the lua script in -- Enable sloppy focus (without defocusing IntelliJ dialogs)
c:connect_signal("mouse::enter", function(c)
local focused = client.focus
if focused
and focused.class == c.class
and focused.instance == "sun-awt-X11-XDialogPeer"
and c.instance == "sun-awt-X11-XFramePeer"
then
return
end
if awful.layout.get(c.screen) ~= awful.layout.suit.magnifier
and awful.client.focus.filter(c) then
client.focus = c
end
end)something similar can be found in i3 workarounds for Java applications: https://stackoverflow.com/a/32596391/ also found in GitHub here "Kludge IntelliJ IDEA splash popup to be transient": Perhaps we need some kludges for IntelliJ in Pop-OS Shell? |
|
I used this type of shell function to get information about the popup dialog: function show_info_for_new_jetbrains_windows() {
ws=$(xdotool search --onlyvisible --class 'jetbrains.*')
while true; do
wstmp=$(xdotool search --onlyvisible --class 'jetbrains.*')
wsnew=$(diff <(echo "$ws") <(echo "$wstmp") | awk '/^>/ {print $2}')
echo found windows: $wsnew
for win in $wsnew; do
xwininfo -id $win -all
xprop -id $win
done
ws=$wstmp
sleep 0.5
done
}(function based on script in raboof/notion#321 (comment)) Here's the output for the "Find in Files" popup dialog in IntelliJ Idea Ultimate: |
|
Switching to the wrong active window seems to be caused by this piece of code: This helped find another workaround:
|
|
@mmstick I have created a PR that fixes this issue. Please review #1007 . Thanks to @sitepodmatt for pointing out the root cause of the issue. |
(1) Issue/Bug Description
When using window stacking, popos changes active stack window when a IntelliJ IDEA based product in a stack application launches a dialog (such as Settings)
(2) Steps to reproduce (if you know):
Create a popos stack
Add a Jetbrain's IntelliJ IDEA (could also be a variant such as WebStorm, Rider, CLion, PyCharm, PhpStorm or RubyMine, DataGrip, AppCode or Android Studio)
Add another app such as Firefox.
Do an action that launches a dialog from the IntelliJ such as opening settings (File -> Settings) popos shell needlessly switches the stack to the wrong window.
(3) Expected behavior: No switching of my stack
(4) Distribution (run cat /etc/os-release): Pop!_OS 20.10
(5) Gnome Shell version: 3.38.1
(6) Pop Shell version (run apt policy pop-shell or provide the latest commit if building locally):
1.0.0
160468824220.10~d1d2b0e(7) Where was Pop Shell installed from: apt-get install popos-desktop
I found this #407 but it doesn't explain why the stack is changing active window, unless it's expecting the dialog to open as part of the stack and trying to focus it but it isn't there??
Perhaps it should only refocus the stack if a window is actually added to the stack, as the modal appears correctly in all other manners?
The text was updated successfully, but these errors were encountered: