NormalMode: <Enter> bleeding through and modifying bullet name before zoom in.

[awillats]

In normal mode, zooms into a node, but I've noticed recently it's modifying the node names. My guess as to what's happening is somehow the enter keypress is "bleeding through" and splitting / overwriting whatever was under the cursor in normal mode.

I hadn't noticed this happening before, so not sure if it's related to the March 20th changes.
Poking around, it seems like it might be related to

vimflowy/transparentKeybindings.js

Lines 51 to 77 in 82eda14

	Enter: e =>
	{
	const focusedItem = WF.focusedItem();
	if(e.shiftKey && focusedItem)
	{
	goToInsertMode();
	return;
	}
	PrevEnterItem = WF.currentItem();
	if(focusedItem)
	{
	// console.log("transparent Enter (NORMAL) valid focus");
	e.preventDefault()
	e.stopPropagation()
	// WF.zoomIn(focusedItem);
	WF.zoomTo(focusedItem);
	WF.editItemName(focusedItem);
	}
	else
	{
	// WF.zoomIn(WF.currentItem());
	WF.zoomTo(WF.currentItem());
	WF.editItemName(WF.currentItem());
	}
	},

specifically:

vimflowy/transparentKeybindings.js

Lines 64 to 65 in 82eda14

	e.preventDefault()
	e.stopPropagation()

Also looks like there was some mention of bleed through / not stopping propagation previously here:
eaa4596

ZoomIn (ctrl-l) and ZoomOut (ctrl-h) now zoom instantly. The zoom animation was causing input to bleed through - even though event.preventDefault() and event.stopPropagation() was being called.

[awillats]

I've trying rolling back to some other recent commits (dcbb385, 9da44aa) , and I still have the same issue, so maybe it's a change on the WF side or with Chrome?

[Wojnach]

I suspect that they are adding their event listeners, for their bindings, sooner then Vimflowy does now, and because of that we can't stop the propagation from bubbling up.

I took a look yesterday but couldn't come up with a quick fix. Gonna give it another try later when I find time.

[Wojnach]

pushed a temp fix for the Enter binding cases for now