Strange caret behavior

[grimalschi]

Hello! When I press "Down" many times, I'm getting strange caret behavior.

What i expect:

What I get:

Any plans to fix this?

[hadrysmateusz]

Any progress on this? It's one of the things that keeps me from using the library as it's super un-intuitive.

[alexanderisora]

Any updates on this issue? Thanks.

[hata6502]

Absolutely, this issue is valid to improve UI.
But I have no idea to resolve it.
It may need a DOM hacking.

[grimalschi]

In my project I have solved this problem for another block editor.

I am checking every possible caret position and detect closest one for jump.

On picture red is current caret, blue is candidates and green is a closest position for caret.

There is also some optimisation like line break detection, because there may be 2000 lines and its too much to check every possible caret position.

So it is a solution, it works fast enough and I am ready to share some production code and explain this more.

If you (EditorJS team) are interested, write me https://t.me/grimalschi

[hata6502]

Great!
By using Range and getBoundingClientRect(), it may be able to resolve this behavior.

[hata6502]

Determining caret position when DOWN key pressed:

[neSpecc]

Awesome! We'll check it

[hata6502]

@grimalschi
@neSpecc
Sorry! I gave up this PR: #1453

Is there anyone who can resolve this good feature?
I think it is a good feature request.

[hata6502]

https://developer.mozilla.org/en-US/docs/Web/API/TreeWalker

[hata6502]

Are force options in Caret.navigateNext(force = false) and Caret.navigatePrevious(force = false) used?
I couldn't find where using force options.

$ git grep "navigateNext(" src/
src/components/modules/blockEvents.ts:    const isNavigated = navigateNext ? this.Editor.Caret.navigateNext() : this.Editor.Caret.navigatePrevious();
src/components/modules/blockEvents.ts:    const isNavigated = navigatePrevious ? this.Editor.Caret.navigatePrevious() : this.Editor.Caret.navigateNext();
src/components/modules/caret.ts:  public navigateNext(force = false): boolean {

$ git grep "navigatePrevious(" src/
src/components/modules/blockEvents.ts:      if (Caret.navigatePrevious()) {
src/components/modules/blockEvents.ts:    const isNavigated = navigateNext ? this.Editor.Caret.navigateNext() : this.Editor.Caret.navigatePrevious();
src/components/modules/blockEvents.ts:    const isNavigated = navigatePrevious ? this.Editor.Caret.navigatePrevious() : this.Editor.Caret.navigateNext();
src/components/modules/caret.ts:  public navigatePrevious(force = false): boolean {

If force options are not used, Caret.navigateNext() and Caret.navigatePrevious() should be simplified by removing force options first of all.

[hata6502]

I did it! 🎉
Please check this PR:
#1526
https://deploy-preview-1526--editor-js.netlify.app/

[alexanderjulmer]

Nice. I found some bugs using Safari (Version 14.0.2 (16610.3.7.1.9)) related to the marker.

Situation: Hitting the down arrow key in a line which also contains a marker.
Expected behavior: Caret jumps into the next line
Actual behavior: Caret jumps in front of the marker and is stuck there

Situation: Hitting the down arrow key while caret is inside a marker.
Expected behaviour: Caret jumps into the next line.
Actual behaviour: Caret jumps to the end of the block. Once jumped to the end of the block, the up arrow key doesn't work anymore (left, right and down work).

Situation: Hitting the up arrow key while caret is in approx. second half of last line of a block which also contains a marker.
Expected behaviour: Caret jumps to second last line.
Actual behaviour: Caret jumps to end of block, up arrow key doesn't work anymore.
Note: Only happens, if block contains a marker.

Please see attached a video of the first two issues.

Bildschirmaufnahme.2021-02-16.um.10.24.41.mov

[hata6502]

@alexanderjulmer
Thank you for reporting the critical bug on Safari!
This bug occurs not only #1526 but also next branch.

@neSpecc
I think this bug should be fixed by the next release.

[hata6502]

This bug occurs as <mark> element in Safari only.
This caret moving is uncontrolled by Editor.js, and relied on each browser's behavior.

Umm... I can't know why this bug occurs in next branch rather than https://editorjs.io