disableObjectResizing and disableNativeTableHandles does not work in IE 9 IE10 in CKE 3.x 4.x

[Mike Nicholls]

Tested using IE9 on Windows 7, with both CKEditor 3.6.4 and 4.0 beta. Was able to freely resize images, buttons and input fields, despite disableObjectResizing being set to true.

Example here: ​http://jsfiddle.net/zMwnc/

Tested in IE8 with no issues, the problem appears to be specific to IE9 and higher.

[Jakub Ś]

Reproducible in IE9 and IE10 from CKEditor 3.0.

Fix from #4208 is not applicable for IE9 and IE10

[Jakub Ś]

Perhaps we could implement workadound i have once used:

editor.on( 'instanceReady', function( e )
				{				
					function disableResizing(){
						if(document.all){ //IE							
								window.document.getElementsByTagName('iframe')[0].contentWindow.document.attachEvent('oncontrolselect', function(){return false;});
								//window.document.getElementsByTagName('iframe')[0].contentWindow.document.detachEvent('oncontrolselect', function(){return false;});//enable table and image resize
							}else{ //Firefox						
								window.document.getElementsByTagName('iframe')[0].contentWindow.document.execCommand("enableObjectResizing", false, 'false');
								window.document.getElementsByTagName('iframe')[0].contentWindow.document.execCommand("enableInlineTableEditing", false, 'false');
							}	
					}
					
					disableResizing();
					
					e.editor.on( 'mode', function( ev )
					{	
						if ( ev.editor.mode != 'wysiwyg' )
							return;			
						disableResizing();
					});
				});

[Mike Nicholls]

That workaround seems to prevent resizing, but it also seems to prevent the user from selecting the objects at all (and doing things like using a toolbar button to align an image).

Here's the workaround I'm currently using - I'm not sure if attaching a function to all elements like that will cause problems, but it seems to prevent resizing while still allowing selection.

if( CKEDITOR.env.ie && CKEDITOR.env.version >= 9 ){
	editor.on( "contentDom", function(){
		/*
			The resizestart event does not appear to bubble in IE9+, so we use the selectionchange event to bind
			the resizestart handler directly once the user selects an object (as this is when the handles appear).
			The Microsoft docs (http://msdn.microsoft.com/en-us/library/ie/ms536961%28v=vs.85%29.aspx) say it's not
			cancelable, but it seems to work in practice.
		*/
		var cancelEvent = function(){
			return false;
		};
		editor.document.on( "selectionchange", function(){
			var selection = editor.document.getSelection(), elem;
			if( selection.getType() === CKEDITOR.SELECTION_ELEMENT ){
				elem = selection.getSelectedElement();
				elem.$.onresizestart = cancelEvent;
			}
		} );
	} );
}

[Jakub Ś]

@miken I have tried your workaround in CKEditor 4 and unfortunately it didn't work there. I have prepared another hack/workaround for CKE 4 in IE>=9 based on your solution.

var editor = CKEDITOR.replace( 'editor1', {
				//resize_dir : 'vertical'
				disableObjectResizing : true
			} );		
						
			editor.on('pluginsLoaded', function(evt){
				if( CKEDITOR.env.ie && CKEDITOR.env.version >= 9 ){										
					evt.editor.on( "contentDom", function(){						
						var editable = editor.editable();		
						var doc = editor.document;	
							//The resizestart event does not appear to bubble in IE9+, so we use the selectionchange event to bind
							//the resizestart handler directly once the user selects an object (as this is when the handles appear).
							//The Microsoft docs (http://msdn.microsoft.com/en-us/library/ie/ms536961%28v=vs.85%29.aspx) say it's not
							//cancelable, but it seems to work in practice.						
						var cancelEvent = function(){
							return false;
						};
					editable.attachListener( doc, 'selectionchange', function(event){								
							var netiveStart = doc.getSelection().getRanges()[0].startPath().blockLimit.$;
							if( netiveStart && netiveStart.currentStyle.hasLayout){								
								netiveStart.onresizestart = cancelEvent;								
							}							
						} );
					} );
				}
			});

1. Resize handles show on elements that have Layout (E.g. ​http://www.satzansatz.de/cssd/onhavinglayout.html)
2. It seems that selection of type element is not always returned when clicking on such element (At least in CKE 4).
3. Taking the above into account I have used method that checks if "clicked element hasLayout". The problem is that clicked element is not always the one you think you click thus I have used blockLimit property (this is the hack/workaround). In most cases it returns body but it can also return element having layout. For example - in below code clicking on hr or span inside div will return div (having height!=auto thus having layout) rather than body.

   <div>
   <p>Text in the DIV 1 Click</p>
   
   <div style="height: 30px;">
   <p>Text<strong> in th<span style="font-family: comic sans ms,cursive;">e D</span>IV 2</strong> Click</p>
   </div>
   <p>&nbsp;</p>
   <hr /></div>
   <p>&nbsp;</p>
   

[Jakub Ś]

Other issues that concern objectResizing #10197, #10252. Please NOTE that #10252 describes Firefox image resize problem.

[Jakub Ś]

#10897 was marked as duplicate.

[Jakub Ś]

#10905 was marked as duplicate.

[Joel]

Add CC. The biggest issue for me is that at least IE9 forces a height for the element after resizing, breaking image proportions (luckily table heights don't seem to have any effect):

<img alt="" src="/Content/images/pel.gif" style="width:10%" />

Converts to

<img alt="" src="/Content/images/pel.gif" style="height:49px; width:23.02%" />

A secondary issue is that after the user resizes an image element and opens the image properties, the width field is empty. For tables the width field contains the new edited value.

On a related note, can support clients add the support keyword or do you developers only do that?

[Jakub Ś]

On a related note, can support clients add the support keyword or do you developers only do that?

We control that. If you have valid license, please write to us on support channel. Please list the tickets you would like to mark and I will then explain in more detail how does it work (Don't forget to specify support token).

[Piotrek Koszuliński]

This ticket is strongly related to #1511. Details in: ​http://dev.ckeditor.com/ticket/1511#comment:17

[Piotrek Koszuliński]

Did not make it to the 4.4.2. Related to #1511 that needed to be postponed too.

[Piotrek Koszuliński]

Replying to j.swiderski:

#10897 was marked as duplicate.

I don't consider #10897 being a duplicate. This ticket is about options disabling native resizing, when #10897 is about visual indication of table selection. We can block resizing (by preventing onresizestart as a last resort) and close this ticket, but it will not solve #10897.

[Marek Lewandowski]

Pushed to ​t/9317 at dev.

TLDR;

We were able to add support for resize blocking in IE8-IE10, it's not possible to do so in IE11.

IE11 workaround:

If someone really wants to remove/disable resize borders for IE (including IE11) he may use

var editable = editor.editable(),
	element = editable.$;

if ( element.addEventListener ) {
	// IE up to 10.
	element.addEventListener( 'mscontrolselect', function( evt ) {
		evt.preventDefault();
	} );
} else {
	// IE11 and higher.
	element.attachEvent( 'oncontrolselect', function( evt ) {
		evt.returnValue = false;
	} );
}

But as a result one will lose drag and drop functionallity, which we need to keep in CKEditor.

Commit notes:

I've also removed

		// ## START : disableNativeTableHandles and disableObjectResizing settings.
		// ## END

markers, since I assumed that this section sie related to disableNativeTableHandles, disableObjectResizing - while it wasn't. Functions there were unrelated.

I've created a separate object to store logic for disabling resize, just to keep onDomReady() function a little shorter.

Also document.execCommand are executed only in FF, because other browsers doesn't support it. Webkit doesn't give any resize helpers, and IE does not handle it, and is ​not willing to implement it any time soon.

[Piotrek Koszuliński]

I wrote a comment under ​https://connect.microsoft.com/IE/feedback/details/742593/please-respect-execcommand-enableobjectresizing-in-contenteditable-elements. It was a really bad decision made by Microsoft and I hope they will rethink their approach.

[Piotrek Koszuliński]

DUP was reported in #12161.

[Piotrek Koszuliński]

1. It's not justified to pack these two functions into object. Worse code minification, inconsistent with surrounding code (even the resizestart listener is outside).
2. version < 11 instead of version <= 10.
3. Instead of beforeSetMode use contentDomUnload.
4. Extract listener to contentDomUnload to function reset and reuse it at the beginning of selectionChange to avoid code duplication.
5. Use editable.attachListener to add selectionChange listener so you won't need to detach it manually on contentDomUnload.

[Marek Lewandowski]

Force pushed to ​t/9317 at dev.

Replying to Reinmar:

1. It's not justified to pack these two functions into object. Worse code minification, inconsistent with surrounding code (even the resizestart listener is outside).

IMHO it make sense to encapsulate this logic into separate function just for readability sake. One does not have to deal with this complexity if he's browsing/working with onDomReady. Function resizeStartListener in fact should be inside the object, I've fixed that.

Code will have worse minification, but will be much easier to maintain.

3. version < 11 instead of version <= 10.

Done.

4. Instead of beforeSetMode use contentDomUnload.

Done.

5. Extract listener to contentDomUnload to function reset and reuse it at the beginning of selectionChange to avoid code duplication.

Event changed, as of reset function created inside of blockResizeStart scope, so it has easy access to variables and can modify them.

6. Use editable.attachListener to add selectionChange listener so you won't need to detach it manually on contentDomUnload.

I tried to use editable#selectionchange it initially, but it seems not to be fired often enough on IE8. Event editor#selectionChange is fired more frequently.

[Piotrek Koszuliński]

Replying to m.lewandowski:

Force pushed to ​t/9317 at dev.

Replying to Reinmar:

1. It's not justified to pack these two functions into object. Worse code minification, inconsistent with surrounding code (even the resizestart listener is outside).

IMHO it make sense to encapsulate this logic into separate function just for readability sake. One does not have to deal with this complexity if he's browsing/working with onDomReady. Function resizeStartListener in fact should be inside the object, I've fixed that.

So you can move this code to a separate function, but not to object. You don't need object, because there's no state, excep and there will be just one function with another function defined inside it. Actually - I'm wrong - there's state, but... you keep it in closure. So why not keeping everything in closure?

6. Use editable.attachListener to add selectionChange listener so you won't need to detach it manually on contentDomUnload.

I tried to use editable#selectionchange it initially, but it seems not to be fired often enough on IE8. Event editor#selectionChange is fired more frequently.

I meant: editable.attachListener( editor, 'selectionChange', ... ), not the native selectionchange event.

[Marek Lewandowski]

Forde pushed to ​t/9317 at dev.

Replying to Reinmar:

Replying to m.lewandowski: So you can move this code to a separate function, but not to object. You don't need object, because there's no state and there will be just one function with another function defined inside it. Actually - I'm wrong - there's state, but... you keep it in closure. So why not keeping everything in closure?

Encapsulating all variables in single object makes it easier to work with later on. And adding eventual workaround for later IE if they'll provide a way to disable these handlers, will be easier.

6. Use editable.attachListener to add selectionChange listener so you won't need to detach it manually on contentDomUnload.

I tried to use editable#selectionchange it initially, but it seems not to be fired often enough on IE8. Event editor#selectionChange is fired more frequently.

I meant: editable.attachListener( editor, 'selectionChange', ... ), not the native selectionchange event.

Fixed. I've missed that I can subscribe to editor events with editable#attachListener - that's what I needed

[Piotrek Koszuliński]

Encapsulating all variables in single object makes it easier to work with later on. And adding eventual workaround for later IE if they'll provide a way to disable these handlers, will be easier.

I simplified this code by removing that object. KISS. So far it's so short that a closure is enough. In the future, if it grows, we can refactor it, but now it wasn't correct.

[Piotrek Koszuliński]

Fixed on master with ​git:00ca2c0. I explained in docs (​git:b32f6052) that this option has a limited effect due to incomplete editing feature implementation in browsers.

[Jakub Ś]

Other issues that concern objectResizing #10197, #10252, #12184, #12772.