id summary reporter owner description type status priority milestone component version resolution keywords cc 8732 CKEditor creating hidden spans which can result in hidden content Duncan Simey Frederico Caldeira Knabben "One of our customers reported instances of text that looked OK when they typed it in to CKEditor, but was missing when the edited HTML was later included in reports generated by our application. Investigation showed their text was inside spans with style display:none We've worked out how to reproduce the problem with Firefox and IE (only checked IE7 onwards), see below. The text inside the display:none spans is only displayed inside CKEditor on some browsers (e.g. IE9 in IE7 document mode). If the person entering the text has one of these browsers then there is no indication that there is a problem. The problem can be reproduced on 3.6.2 Demo and the Nightly Build demo. To reproduce, do the following.... If using IE, turn on JavaScript Alerts using Advanced Internet Options. Paste the following into the editor while in Source mode. {{{

Testing

One

Two

Three

}}} Go back to WYSIWYG mode. Select the word '''Testing''' and use the toolbar to set a background colour; in IE you get a JavaScript error (note the location of the problem). Select the word '''Two''' and use the toolbar to set a background colour; it works fine. Select the word '''Three''' and use the toolbar to set a background colour; in IE you get a JavaScript error (the error details indicate a different location to the first error because it is a different problem). Note: The problem with '''Three''' does not occur with Firefox. Inspect the HTML in Source mode; it now contains weird hidden spans (see below). Clicking after the end of the word Testing and typing some text adds the text into the hidden span. Depending on the exact browser version, the typed text either gets displayed or hidden or sometimes does not go into the hidden span. {{{

 Testing 

One

Two

 Three 

}}} The example above used Background Colour but can be reproduced with any toolbar button which works on selected text (Bold, Font, etc). The HTML comments in the source are what is triggering the problem. During testing we have also observed other ways of producing JavaScript errors and have not yet worked out reproducible test cases. These include an error during paste and an error while changing the selection. Therefore there are at least two more causes of JavaScript errors. The problem is being caused by CKEditor badly handling JavaScript errors. During command execution the source HTML is marked up with hidden spans indicating the start and end of the selected area. These are being added at the start of the command, but are not being tidied up because the script is being aborted by the error. If this was a simple bit of code, then I'd suggest adding a try/catch block where the exception handler cleans up the hidden spans. Whatever solution is proposed, it needs to be generic enough to cope with a range of problems including ones we have not yet worked out how to repeatably demonstrate! There is a related ticket #8232 (Inline styles create empty garbage ""cke_bm_"" spans). This fixed one specific cause of JavaScript error. It did not fix the problem described on that ticket by fastballweb in comment 2. Nor did it fix the general problem of tidying up after exceptions." Bug closed Normal CKEditor 3.6.3 Core : Styles 3.5.1 fixed IE