Closed infokiller closed 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?
Yes sure, I'll try with minimal pristine settings. My computer is pretty fast (beefy desktop from 2017).
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.
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.
If you want to reproduce this, you'll have to also set set updatetime=50
(not necessarily 50, but something low).
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).
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.
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.
@infokiller are you building the browser plugin from source or did you just experiment by removing/adding things to your vimrc?
Using it from the Chrome Webstore and modifying my vimrc
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.