#9317 closed Bug (fixed)
disableObjectResizing and disableNativeTableHandles does not work in IE 9 IE10 in CKE 3.x 4.x
Reported by: | Mike Nicholls | Owned by: | Marek Lewandowski |
---|---|---|---|
Priority: | Normal | Milestone: | CKEditor 4.4.3 |
Component: | General | Version: | 3.1 |
Keywords: | IE9 IE10 IBM | Cc: | Teresa Monahan, Satya Minnekanti, Irina, joel.peltonen@…, matti.jarvinen@… |
Description
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.
Change History (26)
comment:1 Changed 12 years ago by
Keywords: | IE added |
---|---|
Status: | new → confirmed |
Version: | 4.0 Beta → 3.0 |
comment:2 Changed 12 years ago by
Summary: | disableObjectResizing does not work in Internet Explorer 9 → disableObjectResizing does not work in IE 9 IE10 in CKE 3.x 4.x |
---|
comment:3 Changed 12 years ago by
Keywords: | IE9 IE10 added; IE removed |
---|
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(); }); });
comment:4 Changed 12 years ago by
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; } } ); } ); }
comment:5 Changed 12 years ago by
@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; } } ); } ); } });
- Resize handles show on elements that have Layout (E.g. http://www.satzansatz.de/cssd/onhavinglayout.html)
- It seems that selection of type element is not always returned when clicking on such element (At least in CKE 4).
- 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> </p> <hr /></div> <p> </p>
comment:6 Changed 12 years ago by
Version: | 3.0 → 3.1 |
---|
comment:7 Changed 11 years ago by
Summary: | disableObjectResizing does not work in IE 9 IE10 in CKE 3.x 4.x → disableObjectResizing and disableNativeTableHandles does not work in IE 9 IE10 in CKE 3.x 4.x |
---|
comment:8 follow-up: 15 Changed 11 years ago by
Cc: | Teresa Monahan Satya Minnekanti Irina added |
---|---|
Keywords: | IBM added |
#10897 was marked as duplicate.
comment:10 Changed 11 years ago by
Cc: | joel.peltonen@… added |
---|
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?
comment:11 Changed 11 years ago by
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).
comment:12 Changed 11 years ago by
Milestone: | → CKEditor 4.4.2 |
---|
This ticket is strongly related to #1511. Details in: http://dev.ckeditor.com/ticket/1511#comment:17
comment:13 Changed 11 years ago by
Milestone: | CKEditor 4.4.2 → CKEditor 4.4.3 |
---|
Did not make it to the 4.4.2. Related to #1511 that needed to be postponed too.
comment:14 Changed 11 years ago by
Owner: | set to Marek Lewandowski |
---|---|
Status: | confirmed → assigned |
comment:15 Changed 11 years ago by
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.
comment:16 Changed 10 years ago by
Status: | assigned → review |
---|
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.
comment:17 Changed 10 years ago by
Cc: | matti.jarvinen@… added |
---|
comment:18 Changed 10 years ago by
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.
comment:20 follow-up: 21 Changed 10 years ago by
Status: | review → review_failed |
---|
- It's not justified to pack these two functions into object. Worse code minification, inconsistent with surrounding code (even the resizestart listener is outside).
version < 11
instead ofversion <= 10
.- Instead of
beforeSetMode
usecontentDomUnload
. - Extract listener to
contentDomUnload
to functionreset
and reuse it at the beginning ofselectionChange
to avoid code duplication. - Use
editable.attachListener
to addselectionChange
listener so you won't need to detach it manually oncontentDomUnload
.
comment:21 follow-up: 22 Changed 10 years ago by
Status: | review_failed → review |
---|
Force pushed to t/9317 at dev.
Replying to Reinmar:
- 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.
version < 11
instead ofversion <= 10
.
Done.
- Instead of
beforeSetMode
usecontentDomUnload
.
Done.
- Extract listener to
contentDomUnload
to functionreset
and reuse it at the beginning ofselectionChange
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.
- Use
editable.attachListener
to addselectionChange
listener so you won't need to detach it manually oncontentDomUnload
.
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.
comment:22 Changed 10 years ago by
Status: | review → review_failed |
---|
Replying to m.lewandowski:
Force pushed to t/9317 at dev.
Replying to Reinmar:
- 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
. FunctionresizeStartListener
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 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?
- Use
editable.attachListener
to addselectionChange
listener so you won't need to detach it manually oncontentDomUnload
.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.
comment:23 Changed 10 years ago by
Status: | review_failed → review |
---|
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.
- Use
editable.attachListener
to addselectionChange
listener so you won't need to detach it manually oncontentDomUnload
.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
comment:24 Changed 10 years ago by
Status: | review → review_passed |
---|
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.
comment:25 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | review_passed → closed |
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.
Reproducible in IE9 and IE10 from CKEditor 3.0.
Fix from #4208 is not applicable for IE9 and IE10