Deleting and entering newlines (soft enter) at the end of long document causes auto-scroll to top

[tomcdonnell]

📝 Provide detailed reproduction steps (if any)

1. Visit CKEditor demo page: https://ckeditor.com/ckeditor-5/demo/feature-rich/
2. Delete all content from CKEditor field
3. Paste content from attached file (long_text_file_no_html_tags.txt)
4. Scroll to bottom of document
5. Press backspace a few times until a newline is deleted.

✔️ Expected result

No auto-scrolling occurs

❌ Actual result

The page auto-scrolls to the top of the CKEditor field.
(See attached video file for video demonstration)

📃 Other details

• Browser: Firefox 111.0.1 (64-bit)
• OS: Ubuntu 22.04.2 LTS
• First affected CKEditor version: Don't know
• Installed CKEditor plugins: None I think since bug occurs on demo page

---

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

ckeditor_autoscroll_bug_on_demo_page.webm
long_text_file_no_html_tags.txt

[mlewand]

This issue could have the same underlying issue as #14605

[Witoso]

@mlewand AFAICS it happens when the selection lands after delete at the end of a soft brake. The same case as in a code block, right?

[niegowski]

This is happening because this code can't resolve proper client rect and falls back to parent container bounding rect:

ckeditor5/packages/ckeditor5-utils/src/dom/rect.ts

Lines 386 to 407 in cfab99d

	if ( clientRects.length ) {
	for ( const rect of clientRects ) {
	rects.push( new Rect( rect ) );
	}
	}
	// If there's no client rects for the Range, use parent container's bounding rect
	// instead and adjust rect's width to simulate the actual geometry of such range.
	// https://github.com/ckeditor/ckeditor5-utils/issues/153
	// https://github.com/ckeditor/ckeditor5-ui/issues/317
	else {
	let startContainer = range.startContainer;
	if ( isText( startContainer ) ) {
	startContainer = startContainer.parentNode!;
	}
	const rect = new Rect( ( startContainer as Element ).getBoundingClientRect() );
	rect.right = rect.left;
	rect.width = 0;
	rects.push( rect );
	}

[niegowski]

After a deeper checking, I noticed that the range.getClientRects() has a problem resolving screen coordinates if the range is not attached to any text node. In the case of <br/>[]<br/> it fails to return client rect. I noticed that it happens only in the last line (before the final <br> - a block filler). In the other lines there is an inline filler and client rects are resolved properly:

(Note the missing ⁠⁠... - an inline filler, before the block filler)

The line responsible for not adding an inline filler is:

ckeditor5/packages/ckeditor5-engine/src/view/renderer.ts

Lines 525 to 528 in 5028271

	// We have block filler, we do not need inline one.
	if ( selectionOffset === selectionParent.getFillerOffset!() ) {
	return false;
	}

And while checking the getFillerOffset() of the ContainerElement I noticed that it was updated to support block filler after the last <br>:

ckeditor5/packages/ckeditor5-engine/src/view/containerelement.ts

Lines 83 to 86 in 5028271

	// Block filler is required after a `<br>` if it's the last element in its container. See #1422.
	if ( lastChild && lastChild.is( 'element', 'br' ) ) {
	return this.childCount;
	}

but this was not applied to the inline filler logic that should allow for inline filler next to a block filler if this is after another <br>.

[Rashid101]

Where and what is the solution @Witoso ??

[Witoso]

@Rashid101 there's none, this is an open bug on our side. Please +1 (:+1: ), the top comment.