Div editing area – editor viewport is scrolled to the top

[Golan]

Steps to reproduce

1. go to the div editing area demo: ​http://ckeditor.com/demo#div
2. scroll down a bit within the content of the editor
3. focus the cursor within the editor
4. open the anchor dialog
5. either fill in a name and click 'ok' or click 'cancel'
6. Alternatively open any other dialog (such as the link dialog) and click cancel

Expected result

The dialog will close and the editor will keep its scroll position

Actual result

The dialog closes and the editor jumps to the top

Other details (browser, OS, CKEditor version, installed plugins)

Tested on Chrome on Windows 10 - but also happens on other versions of chrome and windows. Didn't manage to replicate the issue on Firefox or Edge.

Although I gave the link to the demo page, we're using the div editing area on our site and this happens to us as well.

[Jakub Ś]

Problem can be reproduced in Blink browsers only on Windows and Mac. It is reproducible from CKEditor 4.0 at least so it might have been introduced by one of browser's update.

[Jakub Ś]

This issue has also been reported on our support channel.

[Jakub Ś]

For anyone looking for the workaround, you could try editing code for dialogs which have this problem. You basically need to restore selection when cancelling dialog. Below is the example for \ckeditor-dev\plugins\table\dialogs\table.js

onCancel: function() {
	if( CKEDITOR.plugins.loaded.divarea ) {
		var selection = editor.getSelection(),
		range = selection.getRanges()[ 0 ];
		range.select();					
	}	
},
onOk: function() {
...

I have added this function directly in dialog code but if anyone is looking for a method of fixing it directly on HTML page, he could use:

var editor = CKEDITOR.replace( 'editor1', {
	extraPlugins: 'divarea'
});
CKEDITOR.on( 'dialogDefinition', function( ev ) {					
	var dialogName = ev.data.name;
	var dialogDefinition = ev.data.definition;					
	if ( dialogName == 'link' || dialogName == 'tableProperties' || dialogName == 'table'  ) {	//code fired for specific dialog		
		var oldOnCancel = dialogDefinition.onCancel;
		dialogDefinition.onCancel = function( ) {
			if( CKEDITOR.plugins.loaded.divarea ) {							
				var selection = editor.getSelection(),
				range = selection.getRanges()[ 0 ];
				range.select();
			}	
			
			if( oldOnCancel )
				oldOnCancel.apply(this);
		};
	}
});

You can also add Blink check there if you don't want this to be fired for every brwoser.

[Jakub Ś]

Seems that this fix will not work for spellcheck dialog.

[kkrzton]

It seems the cause of this issue is ​the line which focuses editable area back after the dialog was closed using ​native focus function.

This means this issue can also be reproduced in the following steps:

1. Go to the div editing area demo: ​http://ckeditor.com/demo#div.
2. Scroll down a bit within the content of the editor.
3. Focus the cursor within the editor.
4. Click outside editor (so the editor loses focus).
5. Run CKEDITOR.instances.editor1.editable().$.focus() in the dev console.

Steps 3 and 4 can be omitted, the effect is the same in both scenarios - the editor viewport is scrolled to the top.

[kkrzton]

I prepared a ​simple demo on jsfiddle to illustrate the issue. The one thing to notice is that the contenteditable area is only scrolled to the top if it has no active focus inside.

On the jsfiddle demo when contenteditable area is focused, clicking focus button does not cause any scrolling, but when it is unfocused clicking button scrolls contenteditable and sets focus/caret on the text beginning.

To reproduce the same behaviour and see this difference on the CKEditor demo:

1. Go to the div editing area demo: ​http://ckeditor.com/demo#div.
2. Scroll down a bit within the content of the editor.
3. Run CKEDITOR.instances.editor1.getSelection( true ).getRanges() - it should return empty array which means there is no active selection inside editor area.
4. Run CKEDITOR.instances.editor1.editable().$.focus() in the dev console.

In the above case the editor viewport is scrolled to the top.

1. Go to the div editing area demo: ​http://ckeditor.com/demo#div.
2. Scroll down a bit within the content of the editor.
3. Focus the cursor within the editor.
4. Run CKEDITOR.instances.editor1.getSelection( true ).getRanges() - it should return array with one range which means there is active selection inside editor area.
5. Run CKEDITOR.instances.editor1.editable().$.focus() in the dev console.

In the above case the editor viewport does not scroll.

[kkrzton]

While the editor viewport scrolling is caused by the native browser behaviour it seems that the reasonable solution is to save and restore scrollTop value while refocusing editor (in a similar way how restoring selection is handled on Webkit browsers - ​https://github.com/ckeditor/ckeditor-dev/blob/master/core/selection.js#L46).

[Tomasz Jakut]

Fixed with ​git:a004eec.

[kkrzton]

There was a little adjustment needed for this fix to cover a specific edge case. It was fixed with ​git:1372913.

[Marek Lewandowski]

Added more fixes with ​git:b14308a94146059d8e5f1ea192600470ee3721b9 and couple earlier commits.

[Artem]

Guys,

We can reproduce the issue with 'Image' feature as well. It happens right after close of the dialog.

Steps to reproduce:

1. ​http://ckeditor.com/demo#inline
2. Scroll page down
3. Focus last editor
4. Click on 'Image' on CKEditor Toolbar
5. Click on 'Cancel'

[kkrzton]

Thanks for reporting @artiq5.

It seems like a different case, the divarea editor has scrollbar inside and the issue was about editor viewport which is scrolled on dialog close. In the inline editor the content is not scrollable by itself and here we see the whole viewport is scrolled. Seems like the cause of it may be the floating toolbar, you can see it jumps to the top.

Could I ask you, @artiq5, to create a separate issue for this one?

[Artem]

@k.krzton

​http://dev.ckeditor.com/ticket/14860

[kkrzton]

@artiq5 Thank you, we will take a look into this issue.

[Golan]

This bug is present again in the latest version of chrome (53.0.2785.116 m) :(

[Jakub Ś]

I have reported your findings here: #14894. Thank you for bringing that to our attention.