Bug: Can't select bottom window by mouse-clicking

[A.J.Mechelynck]

Can't select bottom window by mouse-clicking

Happens every time. How to reproduce:
1. :set ch=2 wmh=0 wh=  don't know if relevant
2. Open at least two horizontally split windows
3. Make some window current, other than the bottom one
4. Click the bottom status line.

Actual result:
Nothing happens.

Expected result:
Bottom window should become current, as with ^Wb

Additional info:
- Selecting by mouse works for any window other than the bottom one.
- :version output:


VIM - Vi IMproved 7.0 (2006 May 7, compiled Jul 23 2006 22:50:51)
Included patches: 1-42
Compiled by [EMAIL PROTECTED]
Huge version with GTK2-GNOME GUI.  Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset 
+cindent +clientserver
+clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv 
+cscope +cursorshape
+dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra 
+extra_search +farsi
+file_in_path +find_in_path +folding -footer +fork() +gettext 
-hangul_input +iconv +insert_expand
+jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds 
+localmap +menu +mksession
+modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm 
+mouse_netterm +mouse_xterm
+multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra 
+perl +postscript
+printer +profile -python +quickfix +reltime +rightleft +ruby 
+scrollbind +signs +smartindent
-sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static 
-tag_any_white +tcl +terminfo
 +termresponse +textobjects +title +toolbar +user_commands +vertsplit 
+virtualedit +visual
+visualextra +viminfo +vreplace +wildignore +wildmenu +windows 
+writebackup +X11 -xfontset +xim

+xsmp_interact +xterm_clipboard -xterm_save
   system vimrc file: $VIM/vimrc
 user vimrc file: $HOME/.vimrc
  user exrc file: $HOME/.exrc
  system gvimrc file: $VIM/gvimrc
user gvimrc file: $HOME/.gvimrc
system menu file: $VIMRUNTIME/menu.vim
  fall-back for $VIM: /usr/local/share/vim
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK 
-DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/opt/gnome/include/gtk-2.0 
-I/opt/gnome/lib/gtk-2.0/include -I/usr/X11R6/include 
-I/opt/gnome/include/atk-1.0 -I/opt/gnome/include/pango-1.0 
-I/usr/include/freetype2 -I/usr/include/freetype2/config 
-I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include 
-DORBIT2=1 -pthread -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API 
-I/usr/include/libart-2.0 -I/usr/include/libxml2 
-I/opt/gnome/include/libgnomeui-2.0 -I/opt/gnome/include/libgnome-2.0 
-I/opt/gnome/include/libgnomecanvas-2.0 -I/opt/gnome/include/gtk-2.0 
-I/opt/gnome/include/gconf/2 -I/opt/gnome/include/libbonoboui-2.0 
-I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include 
-I/opt/gnome/include/orbit-2.0 -I/opt/gnome/include/libbonobo-2.0 
-I/opt/gnome/include/gnome-vfs-2.0 
-I/opt/gnome/lib/gnome-vfs-2.0/include 
-I/opt/gnome/include/bonobo-activation-2.0 
-I/opt/gnome/include/pango-1.0 -I/usr/include/freetype2 
-I/opt/gnome/lib/gtk-2.0/include -I/usr/X11R6/include 
-I/opt/gnome/include/atk-1.0 -I/usr/include/freetype2/config -O2 
-fno-strength-reduce -Wall  -I/usr/X11R6/include   -D_REENTRANT 
-D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING  -pipe -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 
-I/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE   -I/usr/include 
-D_LARGEFILE64_SOURCE=1  -I/usr/lib/ruby/1.8/i686-linux
Linking: gcc -L/opt/gnome/lib   -L/usr/X11R6/lib   -rdynamic  -Wl,-E 
-Wl,-rpath,/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE 
-L/usr/local/lib -o vim   -L/opt/gnome/lib -lgtk-x11-2.0 -lgdk-x11-2.0 
-latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 
-lgobject-2.0 -lgmodule-2.0 -lglib-2.0   -L/opt/gnome/lib 
-L/usr/X11R6/lib   -lgnomeui-2 -lbonoboui-2 -lxml2 -lz -lgnomecanvas-2 
-lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 
-latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 
-lgobject-2.0 -lgnomevfs-2 -lbonobo-2 -lgconf-2 -lbonobo-activation 
-lORBit-2 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0   -lXt -lncurses -lgpm 
-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE 
/usr/lib/perl5/5.8.6/i586-linux-thread-multi/auto/DynaLoader/DynaLoader.a 
-L/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE -lperl -lutil -lc 
-L/usr/lib -ltcl8.4 -lieee -lruby -lm




Best regards,
Tony.

Re: vim server ? security hole?

[Nikolai Weibull]

On 7/28/06, Marc Weber [EMAIL PROTECTED] wrote:


In case it's a still a vim issue or we don't wont it it would be easy to
add a accept_remote_orders_from_different_user and let vim send not
only the command but also the username so the server might check..
I'll try to investigate some more time to get to know wether it's as
easy as this to find a running shell and send some keys to it.


Wait...can other users send commands to my Vim?  Yes, as it turns out,
they can.  That is definitely a /big/ security issue.

Bram, this has to be amended immediately.  If other users should be
able to connect to a remote Vim, then at least there should be some
kind of user/password scheme that the user starting the server can set
up.  Allowing anyone to connect to another Vim is definitely not good.

 nikolai

Re: vim server ? security hole?

[Yakov Lerner]

On 7/28/06, Nikolai Weibull [EMAIL PROTECTED] wrote:

On 7/27/06, Bram Moolenaar [EMAIL PROTECTED] wrote:

 Vim uses the X server for communication.  Only users with write access
 to the X server can send a message to Vim.  And if you have write
 access, you are also able to send keystrokes to another process, thus
 you can do anything anyway.  E.g., by sending keystrokes to an xterm in
 which a shell is running.

 That is, I think it works this way.  Perhaps someone with more detailed
 knowledge of X server access restrictions can give a better answer.

Actually, you have to explicitly allow the sending of synthetic
keystrokes to an xterm (the allowSendEvents resource).


Via 'editres protocol', you can remotely manipulate
resources of running xterm (because xterm is Xt application).
I believe that it is possible to turn remotely this
allowSendEvents of xterm (if one has X server access).
Unless this allowSendEvents is treated differently than
other resources; I did not try to write working example.
I don't care, I always run with 'xhost +'.


I don't know,
but perhaps Vim needs to have something similar.

Vim has something similar:
  gvim --servername 
disables clientserver in gvim.

Yakov