Oh interesting, I have narrowed it to

frame = "none"

in neovide/config.toml

Same here, not in any case but very often when I want to write or close a file Neovide hangs, but still recognizes focus und logs key press:

After hitting ':w' Neovide hangs, last log entry:

TRACE [neovide::window::keyboard_manager] Key pressed w ModifiersState(0x0)
TRACE [neovide::channel_utils] UICommand Serial(Keyboard("w"))
TRACE [neovide::window::keyboard_manager] KeyEvent {
    physical_key: Code(
        KeyW,
    ),
    logical_key: Character(
        "w",
    ),
    text: None,
    location: Standard,
    state: Released,
    repeat: false,
    platform_specific: KeyEventExtra {
        text_with_all_modifiers: Some(
            "w",
        ),
        key_without_modifiers: Character(
            "w",
        ),
    },
}

But anyway log still fills with aditional keypress registrations and window focus changes:

TRACE [neovide::channel_utils] UICommand Parallel(FocusLost)
TRACE [neovide::channel_utils] UICommand Parallel(FocusGained)
TRACE [neovide::window::keyboard_manager] KeyEvent {
    physical_key: Code(
        ControlLeft,
    ),
    logical_key: Named(
        Control,
    ),
    text: None,
    location: Left,
    state: Released,
    repeat: false,
    platform_specific: KeyEventExtra {
        text_with_all_modifiers: None,
        key_without_modifiers: Named(
            Control,
        ),
    },
}
TRACE [neovide::channel_utils] UICommand Parallel(FocusLost)
TRACE [neovide::channel_utils] UICommand Parallel(FocusGained)
TRACE [neovide::channel_utils] UICommand Parallel(FocusLost)

Same behaviour on ':x', ':wq' and ':q'

Same here!
With config set to be frame = "none", it hangs everytime I exit with ':qa' or ':xa'

Try this:

diff --git a/src/window/mod.rs b/src/window/mod.rs
index 44c6524..460ba4b 100644
--- a/src/window/mod.rs
    b/src/window/mod.rs
@@ -18,7  18,6 @@ use icrate::Foundation::MainThreadMarker;
 use winit::{
     dpi::{PhysicalSize, Size},
     error::EventLoopError,
-    event::Event,
     event_loop::{EventLoop, EventLoopBuilder},
     window::{Icon, Theme, WindowBuilder},
 };
@@ -314,7  313,8 @@ pub fn main_loop(
     event_loop.run(move |e, window_target| {
         #[cfg(target_os = "macos")]
         menu.ensure_menu_added(&e);
-        if e == Event::LoopExiting {
 
         if window_target.exiting() {
             return;
         }

Duplicate of #2087

Please try using --frame buttonless temporarily.

I'm sorry to say that neither @polachok's supposal nor @crupest mentioned option helped for me.
Neovide still freezes right after writing a file. In some situations I was able to move the cursor once before freeze.

I'm sorry to say that neither @polachok's supposal nor @crupest mentioned option helped for me. Neovide still freezes right after writing a file. In some situations I was able to move the cursor once before freeze.

If both --frame none and --frame buttonless trigger freezing, then it is another case of bug.
If only --frame none triggers it, then it is the same bug of #2087.
@kyoshiro Would you mind double checking you pass --frame buttonless command line option correctly, either with command line argument directly or use a config file?

Hi @crupest, I tested with option frame = "buttonless" in config file and I can confirm the buttons and title bar disappeared. I then opened some files and saving one of those files freezed neovide. Maybe worth to mention, that the status line shows these symbols when it came to freeze:

@kyoshiro Well, really thank you for your testing. It's just a little weird because I can't reproduce the bug in my situation. Only --frame none freezes on my machine and --frame buttonless does not. If you are willing, maybe you can try another GUI app of neovim and see if it freezes in your case. If it does not, then it is definitely a bug of neovide.

@kyoshiro And the bug should only trigger when you quit neovim with :q or other quit command. But based on what you said, just :w triggers the hanging.

Hi @crupest yes, I will give it some more testing 2mrw. In my experience the hanging happens on :w :x :wq or :q. This does not occur when using nvim natively in terminal or tmux and I also did not recognize the hanging in neovide on Linux. So, it's kind of detective work on Mac right now but I like to figure it out.

From the logs it looks like the event loop does not exit for some reason, even window_target.exit(); is repeatedly called, there's a repeated log of "Saved Window Settings", which implies that it's called, since it's inside the same if block.

And I think we have debugged this already once in Discord, but I can't find it right now, and commenting out save_window_size should "fix" the issue.

The cause is quite probably this, from https://rust-windowing.github.io/winit/winit/platform/macos/index.html

A lot of functionality expects the application to be ready before you start doing anything; this includes creating windows, fetching monitors, drawing, and so on, see issues #2238, #2051 and #2087.

If you encounter problems, you should try doing your initialization inside Event::Resumed.

I think @falcucci, might look into fixing that at some point.

I found it, starting from here:
https://discordapp.com/channels/896132176091955261/896263894086066216/1194132583701811240

There are some interesting other observations, there like https://github.com/rust-windowing/winit/blob/43f29f048180b24479b5406118f7e04f52befa30/src/platform_impl/macos/window.rs#L905, which modifies the windows attributes in order to determine if it's zoomed or not. So, the resolution might be something different too, maybe to make sure that we call save_window_size only once.

Hi @fredizzimo, great. I commented the save_window_size in window/mod.rs and looks quite good at first glance. Giving it more testing over the day. I also reverted changes made before to have an atomic change here.
My preferred setting for frame is: frame = "transparent" on MacOS.

Unfortunately the problem still exists. It's kind of curious, because it seems to happen more often after time and is reproducable more instantly.

@crupest, @fredizzimo : Okay, I'm 99% sure the behaviour is related to the plugin hashivim/vim-terraform and option gset('terraform_fmt_on_save', '1') and neovide. I narrowed it down, because there were no freezes when editing other files except terraform files. Because most of the day I am doing terraform stuff I got hit by the issue a lot.
So I disabled the setting above to not format terraform files on save ét voilà no freeze any more. Actually, I must say, this happens only in neovide. Although I am not familiar with neovide's saving mechanism, it seems to have a relation with the plugin. I will investigate further.

@kyoshiro That makes much more sense then, though it's very strange only neovide triggers the problem. Maybe @fredizzimo has more insights.

@crupest @fredizzimo I spent some additional time in testing and now I can confirm, it's definitely neovide in combination with terraform fmt. I was able to reproduce the behavior on Linux (Arch), too. So maybe it's time to split this up as I do not know if it's related to the initial opening question of this issue.

Yes, I think there are at least two different causes here. The original issue was reported to happen even with --clean

Just an additional datapoint: I am also seeing the freeze on :q with --frame none, but not with --frame buttonless, and I have never even heard of a terraform file :) . (Mac, latest stable release)

this was fixed after neovim/neovim#28157 got merged.