Popups/new windows behind main window
letkan opened this issue · comments
This happens frequently with GTK apps, I use pcmanfm for files and every time I want to for example rename a file, the popup opens behind the main window. Sometimes if I click on a text file in the file browser Geany opens it behind pcmanfm. Just now I opened a picture in Gimp and the popup for setting the color profile opened behind the main window. Is there any way I can control this? Sometimes even launching a new app it ends up behind other windows that are opened.
What version of labwc is this happening with?
Do you use <focus followMouse="yes" raiseOnFocus="yes" /> by chance?
What version of labwc is this happening with?
0.7.1
Do you use
<focus followMouse="yes" raiseOnFocus="yes" />by chance?
I'm pretty sure I don't, where would those settings be?
I'm pretty sure I don't, where would those settings be?
in ~/.config/labwc/rc.xml (or depending on the packaging in your distro in /etc/xdg/labwc/rc.xml if you don't have a local one in your home directory) See https://labwc.github.io/labwc-config.5.html#focus for what they mean.
I was just looking at rc.xml, I don't have those settings
Can you reproduce the issue when you start labwc in its default configuration like labwc -C /dev/null?
Can you reproduce the issue when you start labwc in its default configuration like
labwc -C /dev/null?
I'll do it this afternoon and get back to you
is pcmanfm running under xwayland or wayland?
is pcmanfm running under xwayland or wayland?
How could I tell? I launch it in Wayland and it's the gtk3 version so I'm guessing it's Wayland
If you press A-Tab it should show up as either [xdg-shell] (wayland native) or [xwayland] (X11) on the left.
It's [xdg-shell]
Can you reproduce the issue when you start labwc in its default configuration like
labwc -C /dev/null?
Unfortunately I can't, with labwc -C /dev/null all I get is the very basic desktop and the menu only has Reconfigure and Exit so I can't launch any application to test. Unless I misunderstood something.
You can start labwc with labwc -C /dev/null -s foot (or whatever your terminal editor of choice is).
You can start labwc with
labwc -C /dev/null -s foot(or whatever your terminal editor of choice is).
Ok, I got it, the behavior is the same, copy/pasted a file in pcmanfm and the popup asking me to rename it went behind the main window.
Thanks for confirming,
This sounds like like some GTK applications are activating themselves via the xdg-activation protocol to be kept on top or something like that. The only other situations I can think of that could cause this is either the followMouse setting or having pcmanfm being set to always on top.
Can you try adding this window rule to your rc.xml config?
<windowRules>
<windowRule identifier="*" ignoreFocusRequest="yes" />
</windowRules>and then start labwc as usual to see if it fixes the issue?
Ok, in regards to pcmanfm, no change (scenario where I copy/paste a file), this operation launches 2 windows, one where you are supposed to rename the file and the other, which displays the progress of the operation. The first one remains behind the main window, the second one, on top. The normal behavior is, main window first, progress second, confirm/change name, last. With Gimp there is improvement, the popup for changing the profile is on top now as it's supposed to.
Actually I just did a test with <windowRule identifier="*" ignoreFocusRequest="no" /> and things are the same as with yes so it's random.
But this works better:
<placement> <policy>automatic</policy> </placement>
All windows are visible, the stupid thing is that the progress window is focused instead of the name confirmation one but it's a decent compromise.
If all the cases you saw involve spawning at least two separate sub windows and then one of them being rendered behind the parent window it could theoretically also point to some bug in labwc while we try to raise all sub windows when the parent window (or one of its sub windows) gets focus. Just to clarify: this doesn't happen when just a single sub window opens on top of its parent window?
Just to clarify: this doesn't happen when just a single sub window opens on top of its parent window
It happened once with Gimp but also, as I mentioned above, it happened more then once to open a text file from the file browser in a text editor which opened behind the file browser instead of in front of it, usually when I had several other windows opened.
Let me know if I'm not clear enough
With the text editor, the first file I click opens in front of pcmanfm, if I click another file, the editor opens it behind pcmanfm
This is about the gtk+ version of pcmanfm not the qt version
How does it behave if you force pcmanfm to run in xwayland mode
GDK_BACKEND=x11 pcmanfm
pcmanfm is an old app, that was designed to run under X, as far as I know it was never ported to
wayland, it mostly works because of gtk+. But even with that, I always had problems making
everything work under straight wayland.
How does it behave if you force pcmanfm to run in xwayland mode
GDK_BACKEND=x11 pcmanfm
Just slightly different. With the copy/paste scenario all windows are visible, the progress window overlaps the main window and it's focused while the confirmation window is unfocused and on a side. But the issue with the text editor is unchanged.
And yes, I know pcmanfm is very old but I've used it like forever, hard to get rid of old habits. I just can't find a decent replacement but I'll keep looking
But the issue with the text editor is unchanged.
Do you mean where you select from file manager, and then the editor opens the file?
Edit to add: is this geany 2.x or the older 1.x version
So, I click a file to open, geany opens the file and gets focus; I click another file to open, geany opens file but pcmanfm stays in focus, geany is behind it. Geany version 2
It sounds like pcmanfm is the problem, since it's what fires off geany.
I'm not sure this is easily solvable from the labwc side.
Just tested Thunar and it behaves the same in regards to Geany
Mousepad editor behaves correctly.
There are multiple issues here, the pcmanfm -> geany one and the pcmanfm rename dialog one.
From how I understand the pcmanfm -> geany issue (please correct me if wrong):
- pcmanfm open, geany not open
- opening a file in pcmanfm
- geany opens, loads the file and is in the foreground like its supposed to be
- switching back to pcmanfm and opening another file
- geany loads the new file but doesn't come to the foreground
If the above is correct that would mean that either pcmanfm or geany do not support the xdg-activation protocol (or it is blocked via the window rule mentioned above). That protocol allows a window to request getting raised and focused by using a token that was received from another application that had keyboard or mouse focus (e.g. pcmanfm). Usually in the scenario described the exchange of the token from pcmanfm to geany would take place over dbus or via an environment variable set by pcmanfm.
Mousepad editor behaves correctly.
That would indicate that geany is the one that doesn't support the xdg-activation protocol.
I'll try to reproduce the issue with the pcmanfm rename dialog.
Edit:
Tried the rename and the dialog appears in front of pcmanfm as expected:
Edit 2:
Could reproduce, if you copy a file to some directory and then copy the same file there again the "Confirm File Replacing" dialog indeed is behind pcmanfm. Not sure if this is a pcmanfm bug or a labwc bug though.
Edit 3:
For the geany issue you could use a small wrapper like this in ~/bin/geany, ~/.local/bin/geany or /usr/local/bin/geany (depends on how your PATH is set up) and made executable:
#!/bin/bash
/usr/bin/geany "$@"
wlrctl window focus geanyThis requires wlrctl which may also be available in your distro repo.
Could reproduce, if you copy a file to some directory and then copy the same file there again the "Confirm File Replacing" dialog indeed is behind pcmanfm.
Since it works once, is there something in the labwc code, that allows it to happen,
but some bitmask, trigger, etc needs resetting after each use, and doesn't get reset?
Did some debugging:
00:00:09.573 [../src/view.c:2022] Moving root window 0xaaaaabdfc820 to front
00:00:09.573 [../src/view.c:1974] moving view 0xaaaaabdfc820 'Confirm File Replacing' to front
00:00:09.573 [../src/view.c:2025] Moving child windows to front
00:00:09.573 [../src/view-impl-common.c:49] [map] identifier=pcmanfm, title=Confirm File Replacing
00:00:09.620 [../src/view.c:2022] Moving root window 0xaaaaabdde100 to front
00:00:09.620 [../src/view.c:1974] moving view 0xaaaaabdde100 'bin' to front
00:00:09.621 [../src/view.c:2025] Moving child windows to front
00:00:09.621 [../src/view.c:1974] moving view 0xaaaaabdf5f50 'Copying files' to front
00:00:09.621 [../src/view.c:2029] Moving originally requested child window 0xaaaaabdf5f50 'Copying files' to front, has parent: yes
00:00:09.621 [../src/view.c:1974] moving view 0xaaaaabdf5f50 'Copying files' to front
00:00:09.621 [../src/view-impl-common.c:49] [map] identifier=pcmanfm, title=Copying files
It seems pcmanfm doesn't properly set the parent on the "Confirm File Replacing" window and also maps it before mapping the "Copying Files" window. So it seems labwc is actually doing the right thing here, that "Confirm File Replacing" window doesn't appear to be a child window of pcmanfm. So this looks like a pcmanfm bug (actually two bugs).
Could reproduce, if you copy a file to some directory and then copy the same file there again the "Confirm File Replacing" dialog indeed is behind pcmanfm. Not sure if this is a pcmanfm bug or a labwc bug though.
It looks like a pcmanfm flaw, as with pcmanfm-qt this works.
@Consolatis , all your assumptions are correct, renaming a file is a pcmanfm issue, geany not getting the focus is geany issue. I tried a different editor (see Mousepad above) and it worked as it was supposed to.
Too bad no one bothered to fix pcmanfm, I'll use thunar/mousepad for labwc, no bugs so far
Thanks for looking into this
Too bad no one bothered to fix pcmanfm
They might not be aware of the issue.