ckeditor5 icon indicating copy to clipboard operation
ckeditor5 copied to clipboard

Cursor jumps to beginning or end of document when navigating through a wrapped line with widgets

Open mikhail-aronov opened this issue 3 years ago • 5 comments

📝 Provide detailed reproduction steps (if any)

ck-simple-block-block-demo.zip

https://user-images.githubusercontent.com/33157375/184384473-e385cacd-0f0b-4043-8cbe-fbdd299dcc0f.mov

  1. Open index.html in sample (this is based on the CKEditor 5 demo)
  2. Narrow the screen width until the line with the blue blocks wraps
  3. Navigate with down arrow key from the top paragraph to the bottom

✔️ Expected result

Cursor should go to the next line

❌ Actual result

Cursor jumps to the end of the document

📃 Other details

  • Browser: Chrome
  • OS: macOS 11.6.8
  • First affected CKEditor version: see demo
  • Installed CKEditor plugins: see demo

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

mikhail-aronov avatar Aug 12 '22 15:08 mikhail-aronov

Most likely, this is a native behavior. We don't do much with arrow keys (as they are bloody hard to handle correctly).

You could check it with a similar markup to our widgets (contenteditable=false and similar styles) without CKEditor 5 to verify whether my guess is right.

Reinmar avatar Aug 17 '22 05:08 Reinmar

@Reinmar Sorry that we dropped this issue and thanks for keeping it open. I'm taking a look again and it looks like you're right. It is related to how createContainerElement adds contenteditable=false. I tried setting contenteditable to true via the console and it works nicely but in trying to use writer.setAttribute('contenteditable', 'true', basicElement); it seems contenteditable does not change. How do you recommend we change the property?

Macrofig avatar Apr 06 '23 23:04 Macrofig

The contenteditable="false" attribute is set by the toWidget() helper (not the createContainerElement()). You could remove the attribute inside the downcast converter:

conversion.for( 'editingDowncast' ).elementToElement( {
	model: 'simpleBlueBlock',
	view: ( modelItem, conversionApi ) => {
		const widget = toWidget( createSimpleBlueBlock( modelItem, conversionApi ), conversionApi.writer );

		conversionApi.writer.removeAttribute( 'contenteditable', widget );

		return widget;
	}
} );

After the above change selection is not jumping to the end of the document but still behaves slightly weird: 2023-04-13 14 29 52

I noticed that this happens only when there is no text node after the last inline widget. Maybe we should solve this issue in the Renderer and use something similar to the inline filler. The same issue can be reproduced using inline images:

2023-04-13 14 44 41

niegowski avatar Apr 13 '23 12:04 niegowski

Thanks @niegowski for the help! I was able to follow your instructions and get our specific use case working. Although, I did have to add our own click handlers to get the anchor tag to behave predictably. Either way, the cursor movements make more sense now.

That said, our specific use case does not have any text nodes so we didn't run into any issues you mentioned. I suspect the concerns you pointed out are something we'll need to keep in mind if we ever have to add text nodes to our use case.

Macrofig avatar Apr 30 '23 15:04 Macrofig

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

CKEditorBot avatar Apr 30 '24 03:04 CKEditorBot

We've closed your issue due to inactivity. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).

CKEditorBot avatar May 31 '24 03:05 CKEditorBot