How to modify the behavior on left/right arroy key press

Customization
, ,
1

Hi

I have developed a plugin for adding bidirectional text support for Logseq, helping users to be able to add their content in RTL and LTR directions. I hope one day this becomes the default behavior in Logseq but before that, with this plugin I want to ensure the right behavior is implemented.

Coming to the issue, it seems logseq manually handles events on key down event when it comes to pressing left/right arrow keys. I couldn’t find any way to change this behavior and as a result, when we are in RTL direction text, pressing left/right arrow keys, the cursor moves to the opposite direction. Surprisingly, there is no issue when the user use modifiers like Shift key.

I tried to use event.preventDefault(). It works on all but the left/right keys. I think the issue resides in some logic within the Logseq core, but I couldn’t find it.

How do we fix this issue? Any workaround can be proposed till then?

My current workaround is to dispatch an event for pressing the opposite key, which is buggy if the user presses such keys at the beginning or the end of the text block (because it first moves in the opposite direction and then takes my moves and in such cases, it behaves abnormally).

2

Welcome. Have you tried to also stopPropagation ?

3

Yes. Nothing has effect when it comes to arrow keys (:arrow_left: :arrow_up_down: :arrow_right:).
I even use preventDefault() and stopPropogration() on keypress and keyup to ensure only keydown affects the move.

4
  • The right arrow gets blocked when I enter this in my console:
    document.addEventListener("keydown", (e)=>{
    if (e.code === 'ArrowRight') {
        event.preventDefault();
        event.stopPropagation();
    }
});
  • Can you check the spelling?
    • It is not stopPropogration
  • Is there anything special in your system?
    • Are your arrow keys typical?
    • Could you try the above code in a clean system (no plugins, custom.js etc.)?
1 Like
5

Thanks for your insight.

Before, I was adding the eventListener to top. Now I changed it so that it runs on window.parent.document which is the document we see in the app (if I am not wrong).

Then when I need to change the behavior, I prevent default and propagation and it seems everything is working fine now.

Just released v0.3.0 of the plugin with this fix.

1 Like