Buffer not redrawn when scrolling after process was suspended

[Isopod]

Neovim version (nvim -v)

0.8.1

Vim (not Nvim) behaves the same?

no (probably, not tested)

Operating system/version

Arch Linux

Terminal name/version

alacritty, kitty

$TERM environment variable

alacritty

Installation

pacman -S neovim

How to reproduce the issue

0. Open a file in nvim 0.8.1. The file needs to be large enough so you can scroll in it.
1. Create two vertical splits (I don't know if this is needed)
2. Edit the file, scroll around, do your usual stuff
3. Ctrl-Z
4. Do something else, like compiling your code
5. fg
6. Goto step 2

After doing this for like 30 minutes, the active split stops redrawing when scrolling. Unfortunately, I'm not able to trigger this bug artificially. It just happens during my regular usage. But it is predictable in so far that it happens every single day, usually within the first hour.

I originally experienced this in alacritty, but I also just got it in kitty, so I don't think the terminal is at fault. I didn't have this problem in nvim 0.7.

Expected behavior

Buffer should be redrawn when scrolling

Actual behavior

Here is a screen recording (this one was recorded in kitty):

nvim-0.8.1-annoyance.mp4

After bringing nvim to the foreground with fg, you can see me try to use the mouse wheel. But this doesn't update the buffer, it only jiggles the cursor around (the buffer is still scrolled internally, it's just not drawn on the screen). It doesn't matter whether I use the mouse wheel or any other command like gg, G, 100gg etc. I can see the cursor being moved around, but the text isn't scrolled. Only after I temporarily focus the other pane does it start to work again. But after pressing Ctrl+Z and typing fg a second time, the problem is back.

This is seriously starting to make nvim unusable to me. The most annoying part is that I often don't notice it right away, start editing, and then get syntax errors in all the wrong places. Only to realize that I edited a completely different line. I'm surprised that I haven't found an existing issue. Am I the only one experiencing this? Is it the fault of a plugin (I don't use that many)? Does anyone have any idea what might be causing this?

[zeertzjq]

30 minutes... Maybe some integer overflowed?

[Isopod]

Well, this took a while to bisect, since I had to wait for at least a day to determine if a commit was “good”, but now I finally have the result:

first bad commit: [19e8073] fix(screen): restart win_update() if a decor provider changes signcols (#18768)

git bisect log

git bisect start
# status: waiting for both good and bad commits
# bad: [935615ffeddee2839bb5ac92c3c8e30baa882923] NVIM 0.8.1
git bisect bad 935615ffeddee2839bb5ac92c3c8e30baa882923
# status: waiting for good commit(s), bad commit known
# good: [e8ee6733926db83ef216497a1d660a173184ff39] NVIM v0.7.2
git bisect good e8ee6733926db83ef216497a1d660a173184ff39
# good: [333ba6569d833e22c0d291547d740d4bbfa3fdab] NVIM 0.7
git bisect good 333ba6569d833e22c0d291547d740d4bbfa3fdab
# bad: [86f0da922fbf37278abd62a0fb90fe7e2452ad93] fix: remote UI may get invalid 'pumblend' value #19379
git bisect bad 86f0da922fbf37278abd62a0fb90fe7e2452ad93
# good: [1b235fe6cab237e3cb78a44ee82ab79a85370f98] docs(options): move all removed options to vim_diff.txt (#18770)
git bisect good 1b235fe6cab237e3cb78a44ee82ab79a85370f98
# bad: [bafb53604a5b03fdc319f49d5c45f71df16038c1] vim-patch:8.2.3484: crash when going through spell suggestions
git bisect bad bafb53604a5b03fdc319f49d5c45f71df16038c1
# bad: [e420cd6c67a0aad5b5dcb40748f733876e66a2c3] test: dismiss quit_more from Lua #11226
git bisect bad e420cd6c67a0aad5b5dcb40748f733876e66a2c3
# bad: [86cc33a46412081779b8e6d147c76a2d4d0d7f0f] fix(filetype): fix typo in starsetf function (#18856)
git bisect bad 86cc33a46412081779b8e6d147c76a2d4d0d7f0f
# good: [7380ebfc17723662f6fe1e38372f54b3d67fe082] Merge pull request #18194 from famiu/feat/usercmd_preview
git bisect good 7380ebfc17723662f6fe1e38372f54b3d67fe082
# bad: [285f6518e6d4e94441742d3eb87187f1d24d122a] Merge pull request #18831 from dundargoc/ci/disable-perl-macos
git bisect bad 285f6518e6d4e94441742d3eb87187f1d24d122a
# good: [c632f64e247c672e425f609bb47a9ab0517a4c31] Merge pull request #18583 from gpanders/path-root
git bisect good c632f64e247c672e425f609bb47a9ab0517a4c31
# good: [9f1ec825cdcb5e2f4bd8c7b15b50fb763ddd5cca] refactor(clang-tidy): remove nested redundant ifdefs #18811
git bisect good 9f1ec825cdcb5e2f4bd8c7b15b50fb763ddd5cca
# bad: [209824ce2c6d37332079e6e213d4b8e257d7d53b] fix(lsp): adjust offset encoding in lsp.buf.rename() (#18829)
git bisect bad 209824ce2c6d37332079e6e213d4b8e257d7d53b
# bad: [19e80738e03f352602ec573d3634d53cb6cd09f7] fix(screen): restart win_update() if a decor provider changes signcols (#18768)
git bisect bad 19e80738e03f352602ec573d3634d53cb6cd09f7
# first bad commit: [19e80738e03f352602ec573d3634d53cb6cd09f7] fix(screen): restart win_update() if a decor provider changes signcols (#18768)

@zeertzjq Could you have a look at this?

[zeertzjq]

Thanks. Can you check:

1. If removing the following line fixes the issue:

diff --git a/src/nvim/drawscreen.c b/src/nvim/drawscreen.c
index 4a300384e..d0f4ee774 100644
--- a/src/nvim/drawscreen.c
+++ b/src/nvim/drawscreen.c
@@ -1029,7 +1029,6 @@ win_update_start:
   DecorProviders line_providers;
   decor_providers_invoke_win(wp, providers, &line_providers, &provider_err);
   if (must_redraw != 0) {
-    must_redraw = 0;
     if (!called_decor_providers) {
       called_decor_providers = true;
       goto win_update_start;

2. If removing these following lines fixes the issue:

diff --git a/src/nvim/drawscreen.c b/src/nvim/drawscreen.c
index 4a300384e..de6bdda71 100644
--- a/src/nvim/drawscreen.c
+++ b/src/nvim/drawscreen.c
@@ -956,9 +956,6 @@ static void draw_sep_connectors_win(win_T *wp)
 /// bot: from bot_start to last row (when scrolled up)
 static void win_update(win_T *wp, DecorProviders *providers)
 {
-  bool called_decor_providers = false;
-win_update_start:
-  ;
   int top_end = 0;              // Below last row of the top area that needs
                                 // updating.  0 when no top area updating.
   int mid_start = 999;          // first row of the mid area that needs
@@ -1028,13 +1025,6 @@ win_update_start:
 
   DecorProviders line_providers;
   decor_providers_invoke_win(wp, providers, &line_providers, &provider_err);
-  if (must_redraw != 0) {
-    must_redraw = 0;
-    if (!called_decor_providers) {
-      called_decor_providers = true;
-      goto win_update_start;
-    }
-  }
 
   redraw_win_signcol(wp);
 

[Isopod]

Thanks, I’ll test it. Will probably get back to you within the next 1-3 days.

[zeertzjq]

Oh wait, have you tested this issue on latest HEAD, or only on commits before v0.8.1?

[Isopod]

Sorry I haven't responded yet, I wasn’t feeling well yesterday and the day before, so I didn’t do any programming. Anyhow, based on my testing so far, it seems like removing the first line (1) was sufficient to fix the issue on 0.8.1.

Tbh I’m not sure if I ever tested the master branch. I do remember that I tried to revert the commit on master, but it resulted in a merge conflict as the code was quite different, so I gave up. I’m running master right now and will see if I can replicate the issue or not.

[Isopod]

Ok, I can now confirm that the issue also happens on master (v0.9.0-dev-535+gec1738a6e).