Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Window Menu Bug on macOS 10.15.2 #992

Closed
isaki opened this issue Dec 13, 2019 · 5 comments · Fixed by #1092
Closed

Window Menu Bug on macOS 10.15.2 #992

isaki opened this issue Dec 13, 2019 · 5 comments · Fixed by #1092
Milestone

Comments

@isaki
Copy link

isaki commented Dec 13, 2019

Describe the bug
The Window menu has many repeated, duplicate entries. This is similar to #566 and #593.

To Reproduce
TBD

Expected behavior
The menu should not have so many duplicates.

Screenshots
image

Environment (please complete the following information):

  • Vim version:
VIM - Vi IMproved 8.1 (2018 May 18, compiled Oct 30 2019 11:57:56)
macOS version
Included patches: 1-2234
Compiled by travis@Traviss-Mac.local
Huge version with MacVim GUI.  Features included (+) or not (-):
+acl               +file_in_path      +mouse_urxvt       -tcl
+arabic            +find_in_path      +mouse_xterm       +termguicolors
+autocmd           +float             +multi_byte        +terminal
+autochdir         +folding           +multi_lang        +terminfo
-autoservername    -footer            -mzscheme          +termresponse
+balloon_eval      +fork()            +netbeans_intg     +textobjects
+balloon_eval_term +fullscreen        +num64             +textprop
+browse            -gettext           +odbeditor         +timers
++builtin_terms    -hangul_input      +packages          +title
+byte_offset       +iconv             +path_extra        +toolbar
+channel           +insert_expand     +perl/dyn          +transparency
+cindent           +job               +persistent_undo   +user_commands
+clientserver      +jumplist          +postscript        +vartabs
+clipboard         +keymap            +printer           +vertsplit
+cmdline_compl     +lambda            +profile           +virtualedit
+cmdline_hist      +langmap           +python/dyn        +visual
+cmdline_info      +libcall           +python3/dyn       +visualextra
+comments          +linebreak         +quickfix          +viminfo
+conceal           +lispindent        +reltime           +vreplace
+cryptv            +listcmds          +rightleft         +wildignore
+cscope            +localmap          +ruby/dyn          +wildmenu
+cursorbind        +lua/dyn           +scrollbind        +windows
+cursorshape       +menu              +signs             +writebackup
+dialog_con_gui    +mksession         +smartindent       -X11
+diff              +modify_fname      -sound             -xfontset
+digraphs          +mouse             +spell             +xim
+dnd               +mouseshape        +startuptime       -xpm
-ebcdic            +mouse_dec         +statusline        -xsmp
+emacs_tags        -mouse_gpm         -sun_workshop      -xterm_clipboard
+eval              -mouse_jsbterm     +syntax            -xterm_save
+ex_extra          +mouse_netterm     +tag_binary        
+extra_search      +mouse_sgr         -tag_old_static    
-farsi             -mouse_sysmouse    -tag_any_white     
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X -DMACOS_X_DARWIN  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       
Linking: clang   -L. -fstack-protector-strong -L/usr/local/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/openssl@1.1/lib -L/usr/local/opt/readline/lib -L. -fstack-protector-strong -L/usr/local/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/openssl@1.1/lib -L/usr/local/opt/readline/lib  -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon       -lm  -lncurses -liconv -framework AppKit   -fstack-protector  -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE 
  • OS: macOS 10.15.2
  • Terminal: GUI

Additional context
This is very reminiscent of a previous bug in this menu; however in this case I did not open windows that were already open (which is my reliable way of triggering the previous bug). I will update this thread once I find a way to reliably reproduce this.

@isaki
Copy link
Author

isaki commented Dec 16, 2019

I can reproduce it when no windows are open. Keep opening and closing the same file from the command line.

image

Steps Taken:

  • touch a file (call it foo.txt)
  • Repeatedly open and close foo.txt with /Applications/MacVim.app/Contents/bin/gvim
  • See the above behavior when all windows are closed

I'm still working on reproducing the version with Windows open. Will update when I have more.

@isaki
Copy link
Author

isaki commented Dec 16, 2019

I've got it for windows open as well.

image

Steps Taken:

  • touch 2 files (foo1.txt, foo2.txt)
  • Open both files with /Applications/MacVim.app/Contents/bin/gvim
  • Repeatedly open and close foo2.txt
  • See the above behavior

@eirnym
Copy link
Contributor

eirnym commented Dec 16, 2019

@isaki It's true, this menu items are connected to the same source.

These additional menus are added and removed by macOS event handlers. The additional check should be done here. AFAIK, any other menus are not duplicated accidentally

@isaki
Copy link
Author

isaki commented Dec 18, 2019

@eirnym Please let me know if there is something you want me to test or if you need more information. I'm more than happy to help in any way I can!

@ychin
Copy link
Member

ychin commented Dec 19, 2019

This seems to be the same bug as the other listed ones (#566), except in Catalina it is worse. I actually haven't upgraded to Catalina yet, but I probably should, but it's really the same issue (I think).

@ychin ychin added this to the snapshot-166 milestone Aug 20, 2020
ychin added a commit to ychin/macvim that referenced this issue Sep 18, 2020
Previously MacVim would see a lot of duplicate window menu items like
"Enter Full Screen" or "Tile Window to Left of Screen" when the user
toggles between two windows. This is because the `setWindowsMenu:` call
was injecting these items, but AppKit isn't smart enough to de-duplicate
them (unlike the window list at the bottom). Just fix this by making a
copy of the main menu before passing it in. This way every time we try
to set a main menu (which happens whenever we jump among Vim windows as
each Vim can have different menu items), it will be set with a fresh one
that doesn't have the injected menu items in it.

Also, set NSFullScreenMenuItemEverywhere to prevent AppKit from
injecting "Enter Full Screen" items. MacVim already has similar menu
items to handle that.

Also, remove old private API call to `setAppleMenu:`. As far as I could
tell this is not useful anymore in recent macOS versions and that line
of code was written in 2008.

Fix macvim-dev#566, Fix macvim-dev#992
ychin added a commit to ychin/macvim that referenced this issue Sep 20, 2020
Previously MacVim would see a lot of duplicate window menu items like
"Enter Full Screen" or "Tile Window to Left of Screen" when the user
toggles between two windows. This is because the `setWindowsMenu:` call
was injecting these items, but AppKit isn't smart enough to de-duplicate
them (unlike the window list at the bottom). Just fix this by making a
copy of the main menu before passing it in. This way every time we try
to set a main menu (which happens whenever we jump among Vim windows as
each Vim can have different menu items), it will be set with a fresh one
that doesn't have the injected menu items in it.

- This also requires adding a refresh functionality because
  adding/removing items to the original menu no longer get automatically
  reflected to the app since it only knows about the copied version.

Also, set NSFullScreenMenuItemEverywhere to prevent AppKit from
injecting "Enter Full Screen" items. MacVim already has similar menu
items to handle that.

Also, remove old private API call to `setAppleMenu:`. As far as I could
tell this is not useful anymore in recent macOS versions and that line
of code was written in 2008.

Fix macvim-dev#566, Fix macvim-dev#992
ychin added a commit that referenced this issue Sep 21, 2020
Updated to Vim 8.2.1719.

Features
====================

Touch Bar improvements
--------------------

Touch Bar now supports submenus, and allows mixed icon/text displays
using `tmenu`. When in edit modes (e.g. insert), it will also display an
emoji picker as well. See `:help touchbar` for documentation. #1084

Fixes
====================

- Window menu no longer shows duplicate "Enter Full Screen" or "Tile
  Window to Left of Screen" entries whenever the user switches among
  different MacVim windows. #566 #992
- Fix issue where going to full screen mode when titlebar appearance is
  set to "hidden" would result in lost focus of the window. #1078
- The password dialog box when using `:!sudo` or other commands that
  require password entry (`macvim-askpass`) will no longer focus on
  Finder, and will keep the focus on MacVim. #1091
- Fix minor wrong tooltip in the "Appearance" preference pane. #1087
- "General" preference pane will now be correctly sized when Sparkle
  updater is disabled (e.g. Homebrew builds). #1089
- Misc issues were fixed by Vim upstream, e.g. `vimgrep` causing a
  crash, and odd behaviors with using Shift-O on the first line. #1082
  #1083

Compatibility
====================

Requires macOS 10.9 or above.

Script interfaces have compatibility with these versions:

- Lua 5.3
- Perl 5.18
- Python2 2.7
- Python3 3.8
- Ruby 2.7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants