Pressing F10 makes desktop unresponsive

Bug #702314 reported by Daniel Kullmann
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
vim (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: vim-gnome

When I press F10 in gvim, activating the menu, and then press Esc to get out of the menu, the rest of the desktop stops responding, i.e. nothing responds to clicks but gvim, and Alt-Tab also does not work. I found a nasty workaround for this problem by restarting metacity from inside gvim, but I realized today that I can also just activate the menu again with e.g. Alt-F, then Esc. This returns the state back to normal.

I don't know whether this is a problem with gvim or with gnome, but I don't have this problem with any other software

Using Ubuntu 10.10

Installed versions:
  vim 2:7.2.330-1ubuntu4
  vim-gnome 2:7.2.330-1ubuntu4

Revision history for this message
Daniel Kullmann (daniel-kullmann) wrote :

I tried to find out what is happening using xev, and it seems that vim grabs mouse and keyboard input when F10 is pressed, but does not release the grab when Escape is pressed afterwards. So this looks like a bug in gvim.

When using F10 and Escape:

EnterNotify event, serial 17, synthetic NO, window 0x5c0001e,
    root 0x15a, subw 0x0, time 16060390, (517,521), root:(2343,609),
    mode NotifyGrab, detail NotifyInferior, same_screen YES,
    focus NO, state 16

KeymapNotify event, serial 17, synthetic NO, window 0x0,
    keys: 70 0 0 0 0 0 0 0 0 16 0 0 0 0 0 0
           0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

FocusIn event, serial 17, synthetic NO, window 0x5c0001e,
    mode NotifyGrab, detail NotifyInferior

KeymapNotify event, serial 17, synthetic NO, window 0x0,
    keys: 90 0 0 0 0 0 0 0 0 16 0 0 0 0 0 0
           0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

VisibilityNotify event, serial 17, synthetic NO, window 0x5c0001e,
    state VisibilityPartiallyObscured

When using Alt-F Escape:

EnterNotify event, serial 13, synthetic NO, window 0x5c0001e,
    root 0x15a, subw 0x0, time 16250658, (421,493), root:(2247,581),
    mode NotifyGrab, detail NotifyInferior, same_screen YES,
    focus NO, state 24

KeymapNotify event, serial 13, synthetic NO, window 0x0,
    keys: 0 0 0 0 0 2 0 0 1 0 0 0 0 0 0 0
           0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

FocusIn event, serial 13, synthetic NO, window 0x5c0001e,
    mode NotifyGrab, detail NotifyInferior

KeymapNotify event, serial 13, synthetic NO, window 0x0,
    keys: 90 0 0 0 0 2 0 0 1 0 0 0 0 0 0 0
           0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

VisibilityNotify event, serial 13, synthetic NO, window 0x5c0001e,
    state VisibilityPartiallyObscured

VisibilityNotify event, serial 13, synthetic NO, window 0x5c0001e,
    state VisibilityUnobscured

Expose event, serial 13, synthetic NO, window 0x5c0001e,
    (1,22), width 191, height 35, count 0

LeaveNotify event, serial 13, synthetic NO, window 0x5c0001e,
    root 0x15a, subw 0x0, time 16254022, (421,493), root:(2247,581),
    mode NotifyUngrab, detail NotifyInferior, same_screen YES,
    focus NO, state 16

FocusOut event, serial 13, synthetic NO, window 0x5c0001e,
    mode NotifyUngrab, detail NotifyInferior

Revision history for this message
krzlew (krz-lewandowski) wrote :

I have exactly the same situation here. I have vim-gnome package 2:7.3.035+hg~8fdc12103333-1ubuntu7 on ubuntu 11.04 (64 bit version).

As a workaround I click with mouse on gvim menu and then esc and keyboard works correctly.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in vim (Ubuntu):
status: New → Confirmed
Revision history for this message
Tim Camper (twcamper) wrote :

Me, too.

Same lock-up after F10, same workaround involving Alt-F then Esc. Considering disabling F10 in gvim via ~/.config/openbox/rc.xml.

Lubuntu 12.04.1, Macbook Air 5,5

from $ aptitude show vim-gtk libgtk2.0-0

package: vim-gtk
version: 2:7.3.429-2ubuntu2.1
Depends: vim-gui-common (= 2:7.3.429-2ubuntu2.1), vim-common (= 2:7.3.429-2ubuntu2.1), vim-runtime (= 2:7.3.429-2ubuntu2.1), libacl1 (>= 2.2.51-5), libc6 (>= 2.15),
         libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.12.0), libgpm2 (>= 1.20.4), libgtk2.0-0 (>= 2.24.0), libice6 (>= 1:1.0.0), liblua5.1-0, libpango1.0-0 (>= 1.14.0),
         libperl5.14 (>= 5.14.2), libpython2.7 (>= 2.7), libruby1.8 (>= 1.8.7.352), libselinux1 (>= 1.32), libsm6, libtinfo5, libx11-6, libxt6, tcl8.5 (>= 8.5.0)

package: libgtk2.0-0
version: 2.24.10-0ubuntu6
Depends: libgtk2.0-common, libatk1.0-0 (>= 1.12.4), libc6 (>= 2.14), libcairo2 (>= 1.6.4-6.1), libcups2 (>= 1.4.0), libfontconfig1 (>= 2.8.0), libgdk-pixbuf2.0-0 (>= 2.22.0),
         libglib2.0-0 (>= 2.31.2), libpango1.0-0 (>= 1.28.3), libx11-6 (>= 2:1.4.99.1), libxcomposite1 (>= 1:0.3-1), libxcursor1 (> 1.1.2), libxdamage1 (>= 1:1.1), libxext6,
         libxfixes3, libxi6, libxinerama1, libxrandr2 (>= 2:1.2.99.3), libxrender1, shared-mime-info
PreDepends: multiarch-support

Breaks: gtk-sharp2 (< 2.12.10-2ubuntu2), gtk-sharp2 (< 2.12.10-2ubuntu2), lxdm (< 0.4.1-0ubuntu6), lxdm (< 0.4.1-0ubuntu6), lxlauncher (< 0.2.2-1ubuntu2), lxlauncher (<
        0.2.2-1ubuntu2), xfdesktop4 (< 4.8.3-2ubuntu4), xfdesktop4 (< 4.8.3-2ubuntu4), libgtk2.0-0 (!= 2.24.10-0ubuntu6)

Revision history for this message
Tim Camper (twcamper) wrote :

I tried vim-gnome (7.3.429 from the debian package maintainers), and the behavior is the same.

Built vim from source (7.3.672 from Bram himself) and the behavior is the same.

My build procedure:

1) $ sudo aptitude purge vim.gtk vim-gui-common vim-runtume vim
2) $ cd /tmp
3) $ hg clone https://vim.googlecode.com/hg/ vim # installed mercurial first
4) $ cd vim/src
5) $ ./configure CFLAGS="-I/usr/include/gtk-2.0 -L/usr/lib/x86_64-linux-gnu/gtk-2.0"
  important!! this line should be in the 'configure' output:
   checking for GTK - version >= 2.2.0... yes; found version 2.24.10
                (no "found version" means no gui gets built, silently)

All this proves is that the bug was not introduced into the Vim code by the
debian people. It could be a Bram bug or a GTK+ bug introduced by
either the debian maintainers or the GTK+ people.

FWIW I also tried vim-athena, but I didn't find it to be a usable option because I couldn't find a way to reset the font size. I doesn't have the F10 problem though, because the menus only respond to mouse clicks, no hot or arrow keys.

Revision history for this message
Tim Camper (twcamper) wrote :

addendum to https://bugs.launchpad.net/ubuntu/+source/vim/+bug/702314/comments/5

NOTE: I originally saw the bug in vim-gtk, and then later in vim-gnome (pkg version 2:7.3.429-2ubuntu2.1.)

NOTE: my build procedure was incomplete, sorry:

6) $ make
7) $ make install

Revision history for this message
Tim Camper (twcamper) wrote :

The cleanest workaround I could come up with:

In my ~/.vimrc.after (but it could go in any of the *rc files vim reads on startup in your config), I remap F10 to something safe and useful.

if has("gui_running")
  " work around linux gui F10 problem by making it a nice safe refresh
  if has("gui_gnome") || has("gui_gtk") || has("gui_gtk2")
    map <F10> <c-L>
  endif

  " other gui related stuff . . .
  . . .
endif

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.