inputRules triggered with a delay + incorrect start/end when applied in reverse

[eric-burel]

Here is a glitch reproducing the issue: https://glitch.com/edit/#!/vintage-mixolydian-clam

1) Check the browser console logs 2) Add a star somewhere in the text 3) Add a star before 4) Click somewhere else and add a letter

Capture vidéo du 23-05-2023 16:16:41.webm

You'll see that the rule is triggered, but its "start" and "end" matches the cursor position, not the match position.

Adding a start then a star after is not a problem

Instead, I would have expected: 1) Ideally, the match to be triggered when adding a star before (this might not be feasible) 2) The "start" and "end" value to match the position of the matching content, not the cursor content (this is the most annoying part)

match.index seems to be relative to the current node so I don't think it can be used either, it won't be the right "start" value when there are multiple nodes in the document

[marijnh]

Glitch.com is, unfortunately, a broken mess. Could you put your script on some other sandbox service? (It won't load for me on glitch)

[eric-burel]

Yes here is a Gist: https://gist.github.com/eric-burel/8f85849192b2d969a0cec77793f7ff78

I've added a video reproduction in the ticket too

[marijnh]

Your RegExp doesn't end in $, which is a requirement noted in the docs. Also, there is no promise about match.index being anything in particular. Possibly you're expecting input rules to work in a way that they don't actually work.

[eric-burel]

Ah ok, I did read about th $ (here for googlers) but didn't understand it was expected in the regex.

Adding the "$" will change the behaviour so that the input rule is not triggered at all when written in reverse. But that's not a blocker.