Description of problem: After starting gvim, either from commandline or from the menu, gnome, or xfce, regardless, the window becomes unresponsive and the whole desktop becomes unresponsive also. Only issuing 'killall gvim' or 'kill -9 <pid>' from a VT gives me back my desktop. Version-Release number of selected component (if applicable): 7.2.13 How reproducible: every time Steps to Reproduce: 1.start gvim 2. 3. Actual results: The window and the desktop stop responding. Expected results: A useful gvim window Additional info: If it's indeed a gvim bug, since plain vim works great, from my little programming backround i'd say it's line 508 from src/gui.c [gui_create_initial_menus(root_menu)]; hope it's of any help.
does gvim start with 'gvim -u NONE -U NONE' ?
Got requested info per mail: It does start, but the problem persists, eg if i try to use its menus(file, edit, ehlp, etc), it locks up and it locks my desktop too, and only a killall from a VT solves it.
Same problem here on an x86_64 system in sync with the "rawhide" tree. After launching gvim, mouse input seems to be grabbed by gvim and only gets released after doing a 'killall gvim' from a virtual console.
Issue does not occur on an equivalent x86 system updated to F10 + updates from Koji. Whereas the x86_64 system from comment #3 is using an ATI Radeon X800 video card, the x86 system is equipped with an Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device This bug is -really- annoying .. Any suggestions how to investigate further into this?
After installing FC10-Snap3 x86_64 from scratch from the live CD after updating several packages of the live system including anaconda, and updating the installed system to current Koji immediately after the first boot from run level 1, gvim behaves correctly. One of the updates (which one?) did the job, so this issue should not be one anymore for F10 final [plus updates].
Well, I meant to write "After installing F10-PR-x86_64 from scratch ..".
Have you tried to reproduce this with a newly created user ?
Yes, but I had done either this or removed all dot directories also during the last weeks after installing each F10 snapshot and preview release respectively. But only now, the focus problem is gone .. As pointed out in comment #4, I hadn't observed this issue on a different x86 system with the same Koji setup.
There were no changes in vim which could have fixed this, I think it is save to assume that something in gtk/glib2 has caused this issue. Does everyone agree that this bugzilla can be closed ?
Hum, after another reboot [from a failed suspend], gvim has again started to grab my mouse focus. In a 2nd essentially empty account, gvim still works as expected. Thus, the story is not over yet ..
Here is the culprit: when sound preference [System > Preferences > Hardware > Sound] "Play sound effects when buttons are clicked" is enabled, then the mouse focus gets stolen by gvim as soon as one of the menu buttons is clicked. Correct behaviour can be restored in the same session by unmarking this option.
No improvement when building with argument --enable-gui=gnome2 instead of --enable-gtk2-check --enable-gui=gtk2 . In the past, the first UI choice used to enable GNOME sound effects for gvim.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
No improvement for current "rawhide" build vim-X11-7.2.060-1.fc11.
Identical VIM versions on F9 and F10 behave differently on their respective platforms: F9: vim-X11-7.2.060-1.fc9 [+] working F10: vim-X11-7.2.060-1.fc10 [-] broken This suggests that the true cuplit may be somewhere in GNOME. In that case, all version >= 2.24.x are affected by this bug because a current snapshot of Ubuntu 9.04 "Jaunty Jackalope" as of 2009-01-20 using GNOME 2.25.x is also plagued by this issue.
Opening a GVIM window and simply trying to close it after a while by clicking the corresponding WM button leads to the message: "[No Name] - GVIM2" is not responding. Looks like a problem with the current GNOME/PA sound infrastructure.
Issue also affects a live spin from "rawhide" as of 2009-02-04: alsa-lib-1.0.19-1.fc11.x86_64 alsa-plugins-pulseaudio-1.0.18-2.fc11.x86_64 alsa-utils-1.0.19-1.fc11.x86_64 gnome-desktop-2.25.90-2.fc11.x86_64 gnome-session-2.25.90-1.fc11.x86_64 kernel-2.6.29-0.78.rc3.git5.fc11.x86_64 pulseaudio-0.9.14-2.fc11.x86_64 pulseaudio-core-libs-0.9.14-2.fc11.x86_64 pulseaudio-esound-compat-0.9.14-2.fc11.x86_64 pulseaudio-libs-0.9.14-2.fc11.x86_64 pulseaudio-libs-glib2-0.9.14-2.fc11.x86_64 pulseaudio-module-gconf-0.9.14-2.fc11.x86_64 pulseaudio-module-x11-0.9.14-2.fc11.x86_64 pulseaudio-utils-0.9.14-2.fc11.x86_64 vim-X11-7.2.088-1.fc11.x86_64
Issue fixed in the latest Ubuntu 9.04 daily-live spin, see https://bugs.launchpad.net/bugs/308713 Can anybody confirm this progress for current "rawhide"? The Ubuntu version is vim-gnome-7.2.079-1ubuntu4 which is older than the "rawhide" version reported in comment #17 which supports the assumption that it is rather a GNOME/PA bug and not a VIM one.
Contrary to comment #18 referring to current Ubuntu 9.04, this issue is still present for current "rawhide" which features vim-X11-7.2.131-1.fc11.
It looks like this issue is gone in current "rawhide": - alsa-lib-1.0.19-3.fc11.x86_64 - alsa-plugins-pulseaudio-1.0.18-3.fc11.x86_64 - pulseaudio-0.9.15-11.fc11.x86_64 - vim-X11-7.2.148-1.fc11.x86_64 Can anybody check against a current F10 w/updates?
For a fully updated F10 live system, the issue persists: - alsa-lib-1.0.19-2.fc10.i386 - alsa-plugins-pulseaudio-1.0.18-2.fc10.i386 - pulseaudio-0.9.14-1.fc10.i386 - vim-X11-7.2.148-1.fc10.i386 Given the identical versions of VIM in F10 and F11, the issue is definitely not a VIM issue but rather an ALSA/PA or GNOME one.
do you have gtk-qt-engine installed ? Remove it and try again, there seem to be some issues with it that could cause such a behaviour. And add a comment here if it worked...
(In reply to comment #22) No, I am currently running a fully updated F10 live image from a USB stick, and there is not a single QT related package installed, in particular not "gtk-qt-engine". Yet, GVIM locks up when button sound effects are enabled.
For a fully updated F10 live system, the issue persists: - alsa-lib-1.0.21-2.fc10.i386 - alsa-plugins-pulseaudio-1.0.21-3.fc10.i386 - pulseaudio-0.9.14-3.fc10.i386 - vim-X11-7.2.148-1.fc10.i386
Looks like #488652 is a dupe of this bug, albeit with a description of the root cause of the bug.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.