[vim/vim] gvim: can't interact with "warning: file has changed since editing started" dialog box (Issue #17760)
Allen Wild
aswild created an issue (vim/vim#17760)Steps to reproduce
- Edit a file in GTK3 gvim in WSL2 using WSLg for GUI applications
- Change the file outside of gvim, switch apps back
- The warning dialog box is presented with "OK / Load File / Load File and Options" options
- I'm unable to click any of the dialog box options or otherwise interact with it. I can press keyboard shortcuts like
lto select options.
This is a regression from patch 9.1.0881 in #16100 - reverting the patch, or replacing GDK_WINDOW_TYPE_HINT_POPUP_MENU with GDK_WINDOW_TYPE_HINT_DIALOG fixes the issue for me.
demo video demonstrating the issue: https://github.com/user-attachments/assets/d64f7165-18a8-451e-bf4b-3bb75f37f09f
Expected behaviour
Should be able to click buttons in the dialog box.
Version of Vim
9.1.1544 (master commit a24f5be)
Environment
WSL2 environment using WSLg and wayland and the GTK3 GUI build.
- Windows 11 24H2
- WSL version 2.6.0.0
- WSLg version 1.00.66
- Linux distro inside WSL is Ubuntu 24.04 with GTK 3.24.41
I haven't yet had a chance to test this on a true Linux desktop system. I'm not entirely sure whether this is really a bug with vim or with the WSLg stack.
Logs and stack traces
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Allen Wild
aswild left a comment (vim/vim#17760)As demoed in the video, this patch to change the window hint from Popup Menu to Dialog seems to fix the issue, but I'm not familiar enough with GTK to know whether this is more or less correct.
diff --git a/src/gui_gtk.c b/src/gui_gtk.c index e8093e7c6..77d41f91f 100644 --- a/src/gui_gtk.c +++ b/src/gui_gtk.c @@ -1791,7 +1791,7 @@ gui_mch_dialog(int type, // type of dialog dialoginfo.dialog = GTK_DIALOG(dialog); dialog_add_buttons(GTK_DIALOG(dialog), buttons); gtk_window_set_type_hint(GTK_WINDOW(dialog), - GDK_WINDOW_TYPE_HINT_POPUP_MENU); + GDK_WINDOW_TYPE_HINT_DIALOG); if (textfield != NULL) {
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Allen Wild
aswild left a comment (vim/vim#17760)Yeah, this doesn't manifest on an actual Linux desktop: Arch with Gnome 44 and GTK 3.24.49, but the Dialog window type hint still seems to work fine.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#17760)does this change still fix the issue that #16100 was fixing?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gabriel
gcb left a comment (vim/vim#17760)not sure if related, but on KDE wayland, this window is not moveable, nor a target for alt+tab. If you alt-tab to the main gvim window there's no way to get back to it sometimes. it's weird.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#17760)@aswild can you check, if your proposed change still fixes the issue that #16100 was fixing?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Allen Wild
aswild left a comment (vim/vim#17760)@chrisbra Yes I will do some testing when I'm able (I upgraded to a new PC and need to get my Linux dual-boot working again which will take some time).
@gcb are you referring to the current behavior with GDK_WINDOW_TYPE_HINT_POPUP_MENU, or while testing a change to GDK_WINDOW_TYPE_HINT_DIALOG?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Allen Wild
aswild left a comment (vim/vim#17760)I finally had a chance to test this out on my laptop:
- GNOME 48, wayland session, Arch Linux
- Built latest master (6b9cf31) with
--prefix=/opt/vim-dev --with-features=huge --enable-gui=gtk3 - Running with no startup files
/opt/vim-dev/bin/gvim -u NONE -U NONE
-
If I revert the changes from #16100 I can't reproduce the original symptoms from #172 - alt-tabbing to the gvim window gives keyboard focus to the popup, the popup can be moved freely, the rest of the gvim window can't be interacted with until I close the popup.
-
The current master with #16100 actually feels worse: the popup is aligned in the top-left of the gvim window rather than in the center and can't be moved. The active button isn't highlighted with a dotted border like active UI elements usually are, and the tab key doesn't change that. But it does function - it gets keyboard focus and pressing Enter selects "OK" or pressing 'L' selects "load file".
-
If I change to
GDK_WINDOW_TYPE_HINT_DIALOG, everything works like test number 1 above.
In none of the cases am I able to get gvim into a state where the dialog box gets hidden or otherwise can't be used. I have a suspicion that this is the sort of thing that might relate to the GTK or compositor versions.
@CS-cwhite - do you still have an Ubuntu 22.04 system that can reproduce the original issue? If you change POPUP_MENU to DIALOG from your patch last year is the issue still resolved?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christopher White
CS-cwhite left a comment (vim/vim#17760)@aswild I do have an Ubuntu 22.04 and have been running with my patch applied over the Ubuntu vim. I am currently at 8.2.3995-1ubuntu2.24 plus my patch. My experience is like your point 1 above --- the popup behaves as I would expect.
I'll try in vim9 when I have a chance to see if that makes a difference.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Gabriel
gcb left a comment (vim/vim#17760)@gcb are you referring to the current behavior with
GDK_WINDOW_TYPE_HINT_POPUP_MENU, or while testing a change toGDK_WINDOW_TYPE_HINT_DIALOG?
Never set any of those. I'm on linux, kde on wayland.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christopher White
CS-cwhite left a comment (vim/vim#17760)I'm seeing popups aligned to the top-left of the window in Google Chrome these days. I wonder if it's a GTK regression.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
nitro322
nitro322 left a comment (vim/vim#17760)I have a very similar problem with gvim dialogs, but not sure if it's related. My problem is with the dialog the pops if you try to close a modified window:
[ QUESTION ]
Save changes to "Untitled"?
It's impossible select No with the keyboard. Tab doesn't work, nor does arrows or any other method I could come up with. Clicking No with my mouse works... but I really don't want to have to depend on my mouse to close an editor window. Pressing Space will trigger Yes, so some level of keyboard interaction works, but I pretty much never want to answer Yes at that prompt - if I wanted to save, I would've done so before existing. I also noticed that the dialog window can't be moved as aswild previously reported.
Originally encountered this a while back on Aurora Linux, but thought it was just something goofy there due to the odd way things are managed on that distro. Now I just hit the same thing on my main desktop running Gentoo after upgrading from 9.1.0794 to 9.1.1652. Downgraded back to the older version and confirmed it restored the previous (correct) behavior. Also tried building current vim from source, but still have the same inability to navigate or answer No to dialogs with my keyboard.
I run KDE plasma on both systems, if that may be relevant.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.