glacambre / firenvim

Embed Neovim in Chrome, Firefox & others.
GNU General Public License v3.0
4.78k stars 147 forks source link

Keys are sometimes swallowed #479

Closed infokiller closed 4 years ago

infokiller commented 4 years ago

In some websites I run into "swallowed keys", which means some keypresses are not registered in the firenvim iframe. I ran into this issue in versions prior to 0.1.23, but it was inconsistent. Now I noticed that I can reproduce it pretty consistently on https://ticktick.com (web task manager, requires an account) when editing the main task content. One of the symptoms of this issue is that the neovim iframe is flickering (it always happens when I encounter this issue). When editing Github comments it seems to work fine.

glacambre commented 4 years ago

I can't reproduce this. Could you try with a fresh chrome profile+an empty Firenvim config? Also, is your computer fast or slow?

infokiller commented 4 years ago

Yes sure, I'll try with minimal pristine settings. My computer is pretty fast (beefy desktop from 2017).

infokiller commented 4 years ago

Just to update that this issue also happens on one of my laptops (relatively powerful but less than my desktop). It has the exact same flickering behavior: the iframe flickers after pressing a key, which seems to indicate that the focus is back to the page for a small duration. If I type any other keys during this flickering, the page receives the key, and thus it's not registered by the neovim iframe.

Didn't get to test it with minimal settings yet, hopefully will do it later today.

infokiller commented 4 years ago

OK, I finally got around to debug this. Indeed, this is an issue with the interaction between firenvim and my vimrc. Specifically, the following causes the issue:

function! s:SyncAllBuffers() abort
  silent! wall
endfunction

augroup vimrc
  autocmd CursorHold,CursorHoldI,FocusLost,BufLeave,WinLeave * ++nested call <SID>SyncAllBuffers()
augroup END

This snippet is used to autosave my buffers after the listed events. I assume that firenvim also listens to these events, which causes the issue. I'll take a look at the code.

infokiller commented 4 years ago

If you want to reproduce this, you'll have to also set set updatetime=50 (not necessarily 50, but something low).

infokiller commented 4 years ago

I had more time to debug this. I discovered that the issue is related to the FirenvimAugroupChan autocmds that firenvim creates. This causes the iframe to lose focus for a very small period of time, so the typed keys during that time are received by the original page instead of firenvim. I suspect the reason it happens specifically on ticktick.com is because whatevery firenvim does there takes more time than the average webpage (maybe the DOM is more complex there).

glacambre commented 4 years ago

I discovered that the issue is relate to the FirenvimAugroupChan autocmds that firenvim creates.

This augroup takes care of notifying the browser when the file is written to/when you quit neovim. When notified about file writes, Firenvim synchronizes the buffer's content and the page's input field. It's possible that when Firenvim does this synchronization, the page decides to grab focus. The augroup is probably fired by your CursorHold autocommand.

I am not sure how to work around this, Chrome isn't very friendly to javascript code that tries to control what element is focused.

infokiller commented 4 years ago

Yeah, I'm not sure what can be done either. For now I just disabled my buffer sync autocmd when running in firenvim, and I don't yet see any bad consequences. If I will want to enable my autosaving autocmds again, I'll have to drop the ++nested option. Closing.

glacambre commented 4 years ago

@infokiller are you building the browser plugin from source or did you just experiment by removing/adding things to your vimrc?

infokiller commented 4 years ago

Using it from the Chrome Webstore and modifying my vimrc