Custom Query

According to ​http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-id-attribute - there can't be any spaces in id attribute.

If you put in editor code like:

<p><a href="#first anchor">#first anchor</a></p>
<p>Lots of P</p>
<p><a id="first anchor" name="first anchor"></a></p>

it will work in e.g. Chrome or IE9. If you press preview button then click on link at the top you will see it works and browsers properly do the "jump" to the bottom.

If you put this code in HTML5 Validator you will get 2 messages:

• "Bad value first anchor for attribute id on element a: An ID must not contain whitespace."
• "Bad value #first anchor for attribute href on element a: Whitespace in fragment component. Use %20 in place of spaces."

I think that in this case first message is the one we should focus on and not allow entering spaces into anchor.

Problem can be reproduced from CKEditor 3.6.5 rev. [7618] when id for anchor was introduced.

I have written "if you paste such code" but same code is produced when you create anchor with dialog and then create link to anchor with another dialog.

Background:
It looks that new browsers handle UTF-8 characters in URLs. They show utf-8 characters to user but in background use encoded values to gets right URL.
​http://stackoverflow.com/questions/2742852/unicode-characters-in-urls
​http://stackoverflow.com/questions/6625035/utf-8-characters-in-urls[[BR]] ​http://en.wikipedia.org/wiki/Internationalized_domain_name
It also looks like that old or very old browsers handle encoded values only.

Real-life use case:
It is possible that application has to handle many types of browsers including old ones thus link created in CKEditor e.g. <a href="#első">line1</a> may get transformed to <a href="#els%C5%91">line1</a>. Href value may end up in URL thus it gets encoded on server-side

CKEditor issue: Beacuse of the above, code loaded into editor may look like:

<p><a href="#els%C5%91">line1</a></p>
<p>many lines...</p>
<p><a id="első" name="első">line101</a></p>

If you doble-click on link, link properties dialog will show but value első will not be shown as selected in dropdown.

I think editor should look for both UTF-8 and encoded value (encodeURIComponent perhaps).
The same thing should be done when pressing ok in link properties dialog. It should be checked if current value is első or els%C5%91, next new value should be compared with current one and if they match (probably only if they match) current one should be left. Such check should prevent changing els%C5%91 to első but if application does such transformation on request basis then perhaps this isn't necessary in editor.

Problem can be reproduced from CKEditor 3.0 in both CKE 3.x and CKE 4.x (v4)

Currently it won't create rules from following styles:

font_style: {
	element: 'span',
	attributes: { 'class': '#(family)' },
	overrides: [
		{
			element: 'span',
			attributes: {
				'class': /^Font(?:Comic|Courier|Times)$/
			}
		}
	]
},

fontSize_sizes: 'Smaller/FontSmaller;Larger/FontLarger;8pt/FontSmall;14pt/FontBig;Double Size/FontDouble',
fontSize_style: {
	element: 'span',
	attributes: { 'class': '#(size)' },
	overrides: [
		{
			element: 'span',
			attributes: {
				'class': /^Font(?:Smaller|Larger|Small|Big|Double)$/
			}
		}
	]
}

Perhaps this can be a part of #9991.

CKEDITOR.dtd.customtag = { em:1 };
CKEDITOR.dtd.$block.customtag = 1;
CKEDITOR.dtd.body.customtag = 1;

Load:

<customtag>foo</customtag>

It will be transformed to:

<customtag></customtag>

<p>foo</p>

I think that we don't have to rewrite all code which caches DTD objects because that would ruin performance or increase complexity in some places. Therefore we can introduce event CKEDITOR#dtd fired when DTD is created and allowing its modifications.

Based on: ​http://stackoverflow.com/questions/16066556/ckeditor-how-to-allow-for-inserthtmlcustomtag-myattr-value-customtag

EDIT: The problem is DTD caching makes it impossible to extend it after loading CKEditor source.

Many people will disable ACF because it modifies whatever content exists upon initial load if the classes, attributes, styles... haven't been added to the allowedContent.

A simple example is the stylesheet parser: you have been forced to make it disable the ACF in order to have things work.

Instead, the ACF could have an optional "learn mode" that adds whatever exists in the initial source to the allowedContent for that instance (maybe even configurable to work only on elements/classes/attributes/styles)

So now the stylesheet parser doesn't need to completely disable ACF: the first run of ACF sees some classes that aren't included in the ACF, so it adds those classes. Then the stylesheet is loaded and adds all the desired classes for the content. Nothing has been lost. The user then tries to paste something from an external page and the ACF is run and cleans up removing anything undesired. If the user copies and pastes something inside the editor, then all that content now is allowed and no filtering happens. everyone is happy.

1. Go to any page in editor and clear editor contents (new page command)
2. Switch to source and insert <p>&shy;&nbsp;</p>
3. Switch to WYSIWYG and to Source again

Result: <p>&shy;</p> non-breaking spaced is removed.

Problem occurs in all versions of IE from CKEditor 4.0 (it works in CKE 3.0 - 4.0 beta).

Follow the cases below. Set initial data on the editor, then C-a, C-c, C-v and get data.

• Tested in latest Chrome (26.0.1410.63), Webkit 537.31
• Note that &nbsp;s are displayed always regardless of the alignment.
• Related ticket: #9998

replacebycode (extra &nbsp;, inline style on <a>)

Initial data:

<p style="text-align:right">This is some <strong>sample text</strong>. You are using <a href="http://ckeditor.com/">CKEditor</a>.</p>

After copy and paste:

<p style="text-align:right">This is some&nbsp;<strong>sample&nbsp;text</strong>. You are using&nbsp;<a href="http://ckeditor.com/" style="text-align: right;">CKEditor</a>.</p>

outputhtml (extra &nbsp;)

Initial data:

<p align="right">This is some <b>sample text</b>. You are using <a href="http://ckeditor.com/">CKEditor</a>.</p>

After copy and paste:

<p align="right">This is some&nbsp;<b>sample text</b>. You are using&nbsp;<a href="http://ckeditor.com/">CKEditor</a>.</p>

Based on: ​http://ckeditor.com/forums/CKEditor/How-to-remove-attributes-which-are-removed-from-dialog-windows

It is not possible to modify feature's properties in convenient way or in some cases at all. Editor#feature should be fired when feature is registered by filter#addFeature, but before its rules/transformations/etc are registered.

This should be possible:

CKEDITOR.replace( 'editor1', {
	on: {
		feature: function( evt ) {
			if ( evt.data.name == 'table' )
				evt.data.allowedContent = 'table[border,summary];caption tbody thead tfoot;th td tr[scope]';
		}
	}
} );

To reproduce:

1. Open font menu, scroll down half way and then click away (don't select anything) so it closes
2. Now click the size menu.

Result: It starts scrolled down rather than back at the top.

This is happening because we use 1 float panel for dropdowns and don't reset on every open.
To be honest I have never considered this as a bug. Very common situation is when you try to select something from e.g. styles dropdown and you didn't click what you wanted. If you open dropdown again you will see dropdown in same area where you have finished. You don't have to scroll all the way down what may be frustrating to some (especially when you didn’t click what you wanted for the second time).

Sure when opening new dropdown user would expect it to be at the top. Since we are using one float panel we can either live with it or perhaps remember last dropdown opened and if current dropdown is different scroll it up.

For those who want to have float panel always scrolled up please use below code:

var editor = CKEDITOR.replace( 'editor1', {} );	
editor.on( 'panelShow', function( ev )	{				
	ev.data._.iframe.$.contentWindow.scrollTo(0,0);				
});

Another solution would be adding onOpen methods to below plugins (e.g. after onRender): \ckeditor4-git\plugins\format\plugin.js
\ckeditor4-git\plugins\font\plugin.js
\ckeditor4-git\plugins\stylescombo\plugin.js

onOpen : function(){
this._.panel._.iframe.$.contentWindow.scrollTo(0,0);
},

I am using Inline CKEitor version 4.0.2. I have a ol which has many li tags. In each li, there are contenteditable divs initialized with Inline CKEditors. Now I create a ol/ul list inside the contenteditable div. Next I add some more content below the ol/ul list. Then I select the complete text below the list and complete text of any li together(see attachment for selection) and press enter, the editor crashes.

Here is the stacktrace of the error:

Uncaught TypeError: Cannot call method 'getParent' of null ckeditor.js:139 CKEDITOR.dom.range.setStartBefore ckeditor.js:139 CKEDITOR.dom.range.moveToBookmark ckeditor.js:123 CKEDITOR.dom.selection.selectBookmarks ckeditor.js:331 p.exec ckeditor.js:616 exec ckeditor.js:162 CKEDITOR.tools.extend.execCommand ckeditor.js:195 CKEDITOR.plugins.enterkey.enterBlock ckeditor.js:619 m ckeditor.js:618 a.addCommand.exec ckeditor.js:619 exec ckeditor.js:162 CKEDITOR.tools.extend.execCommand ckeditor.js:195 c ckeditor.js:171 h ckeditor.js:10 CKEDITOR.event.CKEDITOR.event.fire ckeditor.js:12 (anonymous function)

Note: This does not happen if the text is not selected completely either of the li or the text below it. Also, it happens only upon clicking enter. There is no error on clicking backspace. And it does not happen if my CKEdtitor div is not present in an li tag of an ol.

Here is the jsfiddle demonstrating the issue: ​http://jsfiddle.net/FLZhn/1/

I have fount this bug also in 4.0.1 and 4.1.1

Let me know if you have any other queries. Thanks.

Issue reported on our support channel.

In CKEditor 4.1, Image bookmarks are rooted to the documentElement (see CKEDITOR.dom.element::getByAddress). This is probably fine if the editor is in an iframe, but problematic if the 'divarea' plugin is enabled. If an element is inserted before the editor, the selection will be placed in the wrong position (or get an error) when invoking undo.

To reproduce:

1. copy attached sample into samples folder.
2. Open it in browser.
3. Delete character with backspace
4. Wait 500ms and press Undo

Result: Error is thrown - IndexSizeError: Index or size is negative or greater than the allowed amount.

Problem can be reproduced from CKEditor 4.0 beta.

Problem can be reproduced from CKEditor 3.0 in both CKE 3.x and 4.x (v4).

To reproduce:

1. Insert below code in editor

   <div class="mydiv"><span style="font-weight:bold">Bold Text Here</span>
   <div class="freetext">Type here</div>
   </div>
   

2. Put cursor behind Type here^
3. Type few words and press undo or Ctrl+Z

Result: cursor is moved to the beginning of inner div ^Type here

This is continuation of #10292

It seems that menu styles can get broken in IE8-10 when XUA is set to IE8 and compatibility view is turned on.

To reproduce:

1. In replacebycode sample set

   <meta http-equiv="X-UA-Compatible" content="IE=8" />
   

2. In IE8-10 clear cache and set compatibility view to "Display all pages in compatibility view"
3. Load page in browser. Browser should show doc mode set to IE8 and browser mode should have compatibility view.
4. Right click on link or any other element - menu is broken.

Problem can be reproduced from CKEditor 4.0 with both skins (kama and moono).

1. Open enterkey sample and test below code with each enter mode:

   <p>&nbsp;</p>
   <br />
   <p>&nbsp;</p>
   

2. Paste code in source mode, switch to wysiwyg and once again to source.

Results:
Enter_BR: No change and no error

<p>&nbsp;</p>
<br />
<p>&nbsp;</p>

Enter_Div: Br and second P gets wrapped in div. I'm not sure if this is error or not. Perhaps this is how this mode should work?

<p>&nbsp;</p>

<div><br />
<p>&nbsp;</p>
</div>

Enter_P: You get 4 P tags. This is definitely an error as there should be maximum 3 p tags. It looks like code responsible for br replacement matches one P tag to many.

<p>&nbsp;</p>

<p>&nbsp;</p>

<p>&nbsp;</p>

<p>&nbsp;</p>

Problem in enter mode P can be reproduced from CKEditor 4 beta.
As for Div behaviour, guys please leave a comments.

To reproduce:

1. Clear editor contents with New Page command
2. Click image dialog and insert in URL filed assets/sample.jpg
3. Don't click anywhere else and just click OK
4. If you inspect code with dev-tools you will notice that width and height that is by default placed in style attribute isn't present.
5. Double click on image to open its properties.

Result: width and height fields are empty.

Problem can be reproduced in IE9 and IE10 from CKEditor 4.0 Beta

The problem emerged while testing #10027.

Symptoms

We expect command states to be properly set when editor is ready. A state of every context-sensitive command should reflect an initial element path of the editor, the same way command states are updated when selection start changes and element path is updated.

This is, however, working not quite as good as expected. Some commands (and UI buttons) have wrong states when editor starts. This suggests that some actions are unavailable when, apparently, they can be used immediately before clicking in editable and displaying the caret. Of course, the issue has alternatives: some features are TRISTATE_OFF instead of TRISTATE_ON, TRISTATE_OFF instead of TRISTATE_DISABLED etc.

We missed this bug because in most cases "wrong" command states match the initial content of the editor and it's hard to see this as there are so many buttons to be checked. Also we introduced startDisabled property to command definition (i.e. unlink command) to force initial TRISTATE_DISABLED. This creates a delusion of the correct initial state although it takes the advantage of the fact that we hardly ever put <a> tag at the beginning of the content (unlink case).

Examples

Open attached commandstates.html​ in Chrome (the last chapter explains why). Use t/10027 branch as the code basis because this sample uses indentlist plugin.

The first two samples show naive unlink command behavior. Play with ​startDisabled property to see awkward situations.

The third sample should be working just fine, at least in Chrome. The fourth sample explains the origin of this ticket.

Note: when you click the very first editable element in editable (link, paragraph, list element), states are automatically corrected.

Code

So far, the origin of this issue is expected to be within updateCommands() (called on mode and readonly) and updateCommandsContext() (called on selectionChange) ​methods in core/editor.js.

The early debugging (Chrome only) revealed that updateCommandsContext() is called before updateCommands() and it sets corrects states which correspond with the selection. When updateCommands() is executed, correct states get distorted.

This can be "fixed" by changing ​a single line of code to something like this:

this.on( 'mode', function() {
	updateCommands.call( this );
	this.forceNextSelectionCheck();
	this.selectionChange( 1 );
} );

This piece of code is nothing like a gentle solution though. It's ugly and dangerous since it forces updateCommandsContext() once mode is fired. Nevertheless, it brings commandstates.html​ examples back to life by setting correct initial states.

FF and IE "thing"

The dirty fix doesn't work in FF and IE (but it could).

Please note that justify sample doesn't work in FF and IE at all (all justify commands are TRISTATE_OFF). This is because the initial elementPath in these browsers ends in body. See:

CKEDITOR.instances.editor1.elementPath().lastElement

Unfortunately, if we want to fix initial command states, the initial elementPath must be working in FF and IE just like in Chrome. This may be either very simple of very hard to do since the code responsible for initial selection is diffused (referring to talk with Reinmar).

Further testing

I'd love to see all commands tested with different initial contents of the editor. To save time, we could choose 10 or 15 critical and very common commands (buttons) and create tests to assert initial states.

This would protect us from further troubles both in inline and framed instances. We deal with this kind of bugs very often: in almost every single release some command states are fixed. Even if there are tests that check initial states of some commands, they're in different files, hard to develop and control. This approach is weak and we lose time because of this.

Required fixes

• Correct updateCommands & updateCommandsContext order.
• #10483.
• Incorrect selection position after setData on inline editor (described in #10438).
• No selection position (empty elements path) in fresh editor.

Currently only buttons added to toolbar are automatically registered as features. We should also register positions of menubuttons (dropdowns).

Based on: #10440.

Extracted from ticket:10370#comment:3.

Most likely this issue requires lots of coding with no significant improvement to the editor.

Problem is that
inline loads: dataReady, contentDom
framed loads: contentDom, dataReady

This can be checked with:

var editor = CKEDITOR.inline( 'editable' );
	editor.on('contentDom', function(){
		console.log('contentDom');
	});
	editor.on('dataReady', function(){
		console.log('dataReady');
	});

To reproduce:

1. Clear editor contents and inset table
2. Right-click on magic line as shown on image
3. JS error will be thrown

Message: 'getRanges().0' is empty or not an object
Line: 381
URI: ckeditor4/plugins/clipboard/plugin.js

Problem can be reproduced only in IE8

1. Open replacebycode in ​http://nightly.ckeditor.com/ or standard page in ​http://ckeditor.com/demo.
2. Double-click on image (image properties will open)
3. Insert 22 in width field and press OK
4. Double-click on image again.

Result: Width field is showing 22 but image size in preview is the same as first loading the page.

I was able to reproduce this in demo and nightly in all browsers. I wasn't able however to reproduce this on my local machine in default editor (not sure why).

With CKEditor 4 released it's high time to revise the wording of some of our commands and UI elements.

Problem can be reproduced from CKEditor 4.0 beta in Opera and Firefox.

1. Go to read-only sample.
2. Select few words in line
3. Click read-only button to make editor read-only
4. Select few words in line

Result: Cut icon gets enabled. You can't cut text but this doesn't look nice.

This TC is also reproducible in Webkit but enables more buttons plus Webkit has another TC to enable buttons thus it is reported here: #9627

Extracted from #10469.

It would be cool if range#cloneContents preserved id attributes. I also wonder how native implementation handles them.

Follow up of #10438.

1. Download framed_focus.html sample from #10438.
2. Focus editor.
3. Switch to source mode and back to wysiwyg mode.
4. Check that CKEDITOR.instances.editor1.focusManager.hasFocus returns true.
5. Try to blur editor by clicking outside it. No EDITOR#BLUR is logged, focus manager still thinks that editor is focused.

This ticket is required to close #10439.

This is continuation of ​http://dev.ckeditor.com/ticket/10146#comment:26.

Seems ticket isn't fully fixed. Problem can be reproduced in every browser.

To reproduce:

1. Set enter mode to BR
2. Clear editor contents and paste below code:

   <br />
   <br />
   <table border="1" cellpadding="1" cellspacing="1" style="width:500px">
    <tbody>
     <tr>
      <td>Table</td>
     </tr>
    </tbody>
   </table>
   <br />
   <br />
   <hr />
   

3. Switch to WYSIWYG and then to source:

    
   <table border="1" cellpadding="1" cellspacing="1" style="width:500px">
   	<tbody>
   		<tr>
   			<td>Table</td>
   		</tr>
   	</tbody>
   </table>
   &nbsp;
   <hr />
   

Result: As you can see two BR's were changed into single &nbsp;.
If you were writing an article, created table and wanted to make some space above it then on page save you would end up with single &nbsp; which wasn't intended.

NOTE: This is happening if you use one or two BR's. If you use three BR's then result is "br br nbsp". Assuming that last Br has to be changed into nbsp, should it be "br nbsp" when two BR's are used?

It seems ticket #10146 hasn’t been fully fixed thus this one should be closed and the former reopened.
I have just found that if you paste above code into editor, behaviour will be different in IE. All other browsers change two BR’s into &nbsp; but IE does it in "one by one" style – it removes br and on second switch it turns last br into &nbsp;

In latest Chrome:

1. Open replacebycode sample.
2. CTRL+A
3. SHIFT+F10
4. Select "Copy"
5. Hit Enter to close the alert.
6. Editor is empty.

Since v3.

1. Open editor (Replace Textarea Elements by Class Name from Sample).
2. Left-click on image (i.e. apollo image). You will see 8 dots to resize image.
3. Right click on one of these dots.

Error: Permission denied to access property 'nodeType' (line 25)

It seem to be connected with: #9881, #9612

In latest Chrome 27 when you open editor menu with Shift+F10 browser menu also opens. If you try this outside of editor browser menu opens which means that Chrome is using Shift+F10 as shortcut for its native menu.

To reproduce:

• Open replacebycode sample.
• CTRL+A
• SHIFT+F10

Result both menus are opened.

When you have two menus opened press Esc and native one will close. This can be used as workaround but we should block this native menu somehow and make sure that we don’t block it for good as users can turn off editor menu (there is such config option) and use browser native one

Problem can be reproduced from CKEditor 3.0 in both CKE 3.x and 4.x.

1. Open IE8 browser and massive inline creation sample.
2. Click image icon in the toolbar.
3. Enter some image url in the URL text box (e.g. ​http://upload.wikimedia.org/wikipedia/commons/9/95/Ferrari_P4-5.jpg).
4. Click Link tab
5. Enter some url like ​http://www.google.com and click "OK" button
6. Now image when is added in the editor, double-click the image so the link dialog opens.

Results: Now there are two issues.

1. Link URL text box is empty.
2. If I try to enter some URL and press "OK", JS error is thrown:

Message: SCRIPT5007: Unable to get value of the property 'collapsed': object is null or undefined
Line: 1208 URI: /ckeditor4/plugins/link/dialogs/link.js

Problem can be reproduced in IE8 only in inline mode only from CKEditor 4.0 beta

I'd like to gather in this ticket some API improvements we could make. Of course most of them are not obvious, so they can be controversial. Also, in every case backward compatibility should be ensured.

1. CKEDITOR.htmlParser -> CKEDITOR.parser
2. htmlParser.fragment.fromHtml -> htmlParser.parse - this method creates fragments, but also elements (depending on arguments).
3. editable.attachListener
   • Firstly, its name isn't clear and I don't see a chance to make it clear. Therefore I'd rename it to equally unclear editable.on2. Similarly to bookmarks and bookmarks2.
   • Secondly, it is always used with contentDom event. Therefore we can introduce editor.on2 being a combination of both. This should simplify our code, but also would make it simpler to explain that to others. This method would executed listener immediately if editor already has initialized editable and would always register contentDom listener that adds this event again.
4. We can change some get* and set* methods to their simpler versions (*). E.g.: getParent, getFirst, getLast, getPrevious, getNext, getName, getChild, getSelection, getDocument, getRanges, getAttributes, setAttributes, etc. It's for making code easier to write and shorter (in terms of lines length). It won't save a significant number of kbytes (I've made a static analysis and saved ~1% in gzipped package after making even more changes).
5. Editor#instanceReady to #ready (#9911).
6. listener#removeListener to #remove.
7. ?

1. Setup editor

   var editor = CKEDITOR.replace( 'editor1' );
   			editor.on( 'pluginsLoaded', function( evt )
   			{				
   				editor.on( 'contentDom', function( e )
   				{
   					var editable = editor.editable();
   					var doc = editor.document;
   					var wasKeyboardAlreadyUsed = false;
   					editable.attachListener( doc, 'keydown', function( event ) 
   					{							
   						console.log('key');
   					});						
   							
   				});
   			});		
   

2. Open page and insert list into editor
3. Select whole list with mouse and press delete or backspace.

Result: key event isn't caught.

Problem can be reproduced from CKEditor 4.0.

This issue was reported on our support channel.

1. In IE8 open editor with below code

   <p>test</p>
   <ol>
   	<li>test</li>
   	<li>test</li>
   </ol>
   

2. Make the following selection (you get best result with shift+right arrow)

   <p>te^st</p>
   <ol>
   	<li>te^st</li>
   	<li>test</li>
   </ol>
   

3. Press delete key

Result: Ordered list gets changed into unordered one.

Problem can somewhat be reproduced from CKE 3.0 (orphan li elements were left) but this particular TC where one list is changed into another can be reproduced from CKEditor 3.4.2 in both CKE 3.x and 4.x.

A new configuration option should be introduced to restrict magicline focus spaces to some user-selected subset like:

config.magicline_triggers = {hr:1,div:1};

Ticket extracted form the ​pull request.

To reproduce:

1. Open CKEditor demo
2. Click before ^Appollo
3. Press delete and hold it.

Result JS error is thrown.

Message: Invalid argument
Line : 295
URI: /ckeditor4/core/dom/node.js

Problem can be reproduced in both branches CKE 3.x and 4.x. I was able to reproduce it from CKEditor 3.3.

Bug History:
Invalid argument has been thrown from CKEditor 3.3. but it was thrown by different parts of code

• 3.3 - 3.6 - /cke3.6/_source/core/dom/text.js; Line 62;
• 3.6.1 - 4.1.2 - /cke3.6.3/ckeditor/_source/plugins/selection/plugin.js; Line: 911 and|or /cke3.6.6/ckeditor/_source/core/dom/node.js; Line: 234.
• I was not able to get right repository - in source version first error is thrown even in CKE 3.6.2 while in release code till 3.6.1.

Possible reason:

It has turned out in my tests that simple space between image and Apollo word is to blame. If I have removed this space there was no error.

<h1><img alt="Saturn V carrying Apollo 11" class="right" src="assets/sample.jpg" /> Apollo 11</h1>

In CKEditor 4.x this image is aligned to the right and it doesn't look like source of the problem but in older versions there is something extra happening which may prove what I have written.

Copy sample code from CKE 4.x to 3.x - till version 3.3 When you removed image space was left and no error occurred. From CKE 3.3 removing image removes also this space.

1. Open attached sample.
2. Switch to source mode.
3. Error is thrown.

1. Load this HTML:

<ul>
	<li>x
	<ul>
		<li>y</li>
	</ul>
	</li>
</ul>

2. Place the caret after "x".
3. ENTER

Current results:

The new list item will be properly created, but the caret will be blinking right before "x".

Expected results:

The caret should be blinking in the new empty list item.

There should be a sample to show how events works and which event is fired in which case. I think that it should be a list of events and the editor and every time the event if fired a right event on the list should blink.

It should be possible to replace textarea with inline editor using jQuery adapter.

Now jQuery adapter check what is the type of element and if it is textarea it use replace otherwise it use inline so it is not possible do use inline on textartea.

In my opinion the best solution is to create additional configuration option with will be parsed by the adapter i.e.:

$( 'textarea' ).ckeditor( {
   creator: inline
} );

should create editor using inline function.

This is a followup for ticket:10599#comment:3.

Ideally, the "list" plugin should not require "indentlist".

The problem is that there is a execCommand( 'outdent' ) call in the list plugin code, which makes this require necessary.

Additionally, we have removed some tests with (edbb565 @tests), because they were not compatible with this require. If we fix this, we should revert those tests back.

Insert ordered list into editor or open page with list in IE11 compatibility mode. Numbers start from 0.

• Open e.g. replacebycode sample in IE8-11 in compatibility mode or in IE7
• Press BIDI button

Result: some toolbar buttons get very long.

This happens in IE7 by default and in other IEs when they are set in compatibility mode.

1. Insert textfiled into paragraph
2. You will notice there is little space before textfiled and blinking cursor.

Results:

1. If you press delete whole paragraph will be deleted - BUG.
2. If you press left arrow (so that cursor disappears) and then press Backspace only text field will be removed - can be used as temporary workaround.
3. Delete doesn't remove whole paragraph but requires to be pressed twice in order remove textfiled.

This problem can be reproduced in Safari 6 (Mac) and Chrome 28 from CKEditor 3.3.

Before this version there was no tiny space before textfiled and removing worked ok.

When you open samples in basics preset some (most) of them does not work properly (as described). In example:

• Toolbar Configuration: there is long list of toolbarGroups and everything what user see are 9 buttons (​http://dev.ckeditor.com/ticket/10338),
• ENTER Key Configuration: DIV mode doesn't work,
• Using CKEditor JavaScript API: "set editor content" doesn't set expected content (no H2 tag),
• Replace DIV with CKEditor on the Fly: when you start editing any part, the header is changed to standard text so the content is modified event if you do nothing,
• Data Filtering and Features Activation: this sample does not make much sense at all,
• Inline Editing by Code: content looks terrible (there should be different content),
• Full Page Editing: how I can use it (check it) in basics preset?

This is only small list for basic preset and there could be similar problems for standard. I think that for a user who just want to check how basics editor works all of this things look like bugs.

<ol>
        <li>x
            <p>y^</p>

            <ol>
                <li>z</li>
            </ol>
	</li>
</ol>

• When outdenting:

  Uncaught TypeError: Cannot call method 'getParent' of null 
  

• When indenting: Nothing happens, in previous version margin-left added to the outer list.

Extracted from ​the question on SO.

When searching for some text, editor also considers invisible elements. It looks strange when the dialog suggests something was found but nothing is highlighted.

We could at least provide some configuration option to bypass this strange behavior or basically fix it.

Preview tab in DocProps plugin is missing utf-8 meta tag. Because of this all non-latin characters are wrongly displayed.

1. Open editor in std preset.
2. Create list.
3. "Mistakenly" press tab in the first element.
4. Focus is gone.

If we handle tab in all other lists' elements, then it should be blocked in the first one and in all other places where tab does nothing. It cannot be so inconsistent, because this is confusing and irritating. Either tab leaves editable or it indents lists/blocks. Not both at the same time.

This could be configurable by keystrokes - by default tab is added as a keystroke executing 'indent' command. If someone needs it for leaving editable, then he can reset this keystroke. Or the opposite - tab by default can be used for navigation, but it's behaviour can be changed by setting a keystroke.

And yes, there's no good solution ;|.

1. Please insert attached file into plugins folder
2. On sample page please specify

   extraPlugins:'tracking',
   toolbar_Basic : [['Accept' ]]
   

3. Open sample, open menu button and click any option.

Problem: button gets disabled.

This is happening because plugin doesn't use modes: { wysiwyg: 1 }, (If you set it there is no problem). When I was looking through code of button.js plugin I haven't found any lines that sets modes, only lines that use mode property.
This is quite different from command.js which for example set default mode.

I believe that either there should be default mode for menu button or this property should be made required.

Problem can be reproduced in both CKEditor 4.x and 3.x

Problem was described on forum: ​http://ckeditor.com/forums/CKEditor/ckeditor-causes-comments-prefixed-by-in-subsequent-scripts-to-be-executed-as-code-in

CKEditor uses conditional compilation to determine whether it is ran on IE. If CKEditor's source file is followed (even indirectly) by:

//@

or:

/*@

IE will parse this comment as a CC statement (although, I have no idea why :|) causing a very likely syntax error.

Possible workarounds:

• load CKEditor source after script with such comment,
• do not use @ right after comment start (space is enough).

We might need a special support for marking parts of code that are needed for testing and should be removed in release version. In short, they should be left in "test release" version.

Sample code: ​https://github.com/cksource/ckeditor-dev/blob/t/9764/plugins/widget/plugin.js#L420-L428

		// %REMOVE_START%
		// Expose for tests.
		,
		getNestedEditable: getNestedEditable,

		createEditableFilter: createEditableFilter

		// %REMOVE_END%
	};

This is a FF's only issue. Currently (and this is a state from 3.0) Editor.insertElement will take passed element, clone it multiple times and insert into every range. This is a surprising behaviour, because we lose control over inserted element - we keep the reference only to one of them.

Correct behaviour IMO would be to clean all ranges and insert element only to the first (or last?) of them.

While working on this ticket it would be worth to review and correct insertHtml which does not clean other ranges when doing insertion.

The icons.png generated by the local version of CKBuilder includes all the images instead of just the used icons like the online version does.

Go to ​http://ckeditor.com/download and download the Basic package. Now use the included build-config.js in a local version of CKEditor and use the build.sh script

Compare both icons.png files and you'll see that instead of 7Kb it's 17Kb and includes all the plugins.

Hey guys, The UI languages sample aims to show that the editor could be used in an RTL environment. While the basic goal of this sample is indeed reached (the UI does show up in Hebrew), it's worth showing some of the appropriate BiDi features CKEditor has to offer. When one changes the UI language in the sample, he might expect to try and write something using the chosen language. Currently, if the language is changed to (e.g.) Hebrew, the cursor stays on the left and the text is actually written as LTR. This could be solved either by changing the default writing direction on this sample accordingly, or at least by providing LTR/RTL and alignment buttons on the toolbar. P.S - "Try "arabic" or "hebrew" to check RTL support:" - Arabic and Hebrew should be capitalized (proper nouns). Just my two cents :)

1. Open inlinebycode sample.
2. Select two cells.
3. Right click -> cells -> merge cells.
4. Nothing happened - only left cell is selected. In the error console the following is reported:

   TypeError: e.getDocument is not a function
   

To debug add if ( !isDetect ) debugger; statement at the beginning of mergeCells function. See that when this function is called the selection is already broken, so only one cell is returned from getSelectedCells.

Note: mergeCells is called with isDetect flag when opening ctx menu and at this point selection is correct.

Working on #10689 I realized that ​this part of code works magicly:

// #8031 If textarea had required attribute and editor is empty fire 'required' event and if
// it was cancelled, prevent submitting the form.
if ( editor._.required && !element.getValue() && editor.fire( 'required' ) === false ) {
	// When user press save button event (evt) is undefined (see save plugin).
	// This method works because it throws error so originalSubmit won't be called.
	// Also because of hack there is try-cache in save plugin so error won't be shown.
	evt.data.preventDefault();

It should be fixed using save event instead of submit.

Open: ​http://ckeditor.com/demo# or samples/datafiltering.html#

See that page is scrolled down.

Reported on: ​http://ckeditor.com/forums/CKEditor/Scrolling-problem-when-using-empty-anchor-in-URL

1. Create a form with submit button.
2. Create several inline-textarea instances within the form.
3. Submit the form.

Then what happens:

• In Chrome, for each instance, an error is thrown:

  An invalid form control with name='editor1' is not focusable.
  

  • A funny note: when instances have some startup data, there's no error.
• In Firefox, the "Please fill out this field" tip is displayed even if some text was typed inside the instances.
  • A funny note: If there's startup data, submit goes fine.
• In IE9, everything is fine, page submitted, data retrieved.
  • A funny note: There's nothing funny about IE and that makes me worry.

1. Open replacebycode
2. Set the following HTML:

   <p>Hello world!</p>
   <p style="text-align:right"><a href="#">Wooo! I&#39;m so sticky!</a></p>
   

3. Select the paragraph:

   <p>[Hello world!]</p>
   

4. C-c
5. C-a
6. C-v
7. Switch to Source and back to WYSIWYG.

Note there's an unwanted paragraph aligned to the right at the end of editable:

<p>Hello world!</p>
<p style="text-align:right">&nbsp;</p>

Now remove the link from the original content and repeat all the steps. Use the following startup data:

<p>Hello world!</p>
<p style="text-align:right">Yay! I&#39;m not so sticky anymore!</p>

Result is just perfect:

<p>Hello world!</p>

To reproduce:

1. Insert table 1X2 (1 row and two columns)
2. Double (or even triple) click inside table so that whole cell gest selected (You have to see selection in table cell).
3. Right-click on selected cell and choose Column->Delete Column.

Result: Whole table gets deleted.

Problem can be reproduced from CKEditor 4.0.1 in Chrome and Safari only.

1. Open widgetquote sample from #9764.
2. Switch between modes twice in first editor.
3. See that widget lost its styles in second (inline) editor.

Or:

1. Open datafiltering sample from master and find in dev tools last stylesheet (with data-cke-temp attr) in host page's head.
2. Switch between modes twice.
3. Stylesheet was removed...

Problem is somewhere here: ​https://github.com/ckeditor/ckeditor-dev/blob/master/core/editable.js#L681-L693

It seems that framed editor (wysiwygarea or sourcearea) does not increase stylesheet_ref, but it decreases it. Or that order of detach and new editable's setup is incorrect.

1. In latest Safari (6.0.5) open replacebyclass.html
2. Fn+Alt+F10 to focus the toolbar.
3. Using TAB, go to font color toolbar (or any combo).
4. SPACE to enter the palette (or the combo), navigate with arrows.
5. ESC.

Expected: focus goes back to color button in the toolbar so it's possible to select a different toolbar (TAB) or a different button (arrows). This is the behaviour of Chrome.

Actual: focus goes to editable. Need to use the keystroke again to focus it.

1. Remove DOCTYPE declaration (<!DOCTYPE html>) from "User Interface Globalization" sample (samples/uilanguages.html).
2. Open sample in IE 10.
3. Change language to Arabic.

Result: toolbar has wrong styles (see attachment).

4.2.1 is first version with IE 10 QM support.

1. Remove DOCTYPE declaration (<!DOCTYPE html>) from "Replace Textareas by Class Name" sample (samples/replacebyclass.html).
2. Open sample in IE 10.
3. Switch to source mode.

Result: no code formatting (see attachment).

4.2.1 is first version with IE 10 QM support.

since: 4.0 until master
issue not found in 3.6.6.1 though

1. open any sample with CKEditor (i.e. samples/replacebyclass.html)
2. using "Templates" button from toolbar, insert template "Text and table" (replacing current content)
3. click "Table title" in order to edit it
4. press Home key
5. press Shift+End key

Expected result:
Table caption text should be selected.

Current result:
Caret does not move, no text is selected. Javascript exception is thrown.

js error:
SCRIPT16389: Unspecified error.
selection.js, line 800 character 5

additional info:
if caption has multiple lines, issue occurs only in last line.

​http://docs.ckeditor.com/#!/guide/dev_allowed_content_rules

During works on #9764 we implemented simple time widget. It's not ready to be included in official release yet, so we're extracting it to this ticket.

During works on #9764 we implemented simple captioned quote widget. It's not ready to be included in official release yet, so we're extracting it to this ticket.

Hitting return enough times in a CKEditor field will cause all text below cursor to delete, and will continue to delete text below cursor when pressing return. This is also reproducible using the demo you have online following these steps:

• Go to ​http://ckeditor.com/demo on an ipad:
• Click into CKEditor several lines into text (around Broadcasting and quotes). Hit return 10 or more times.
• Result: Text below initial point is removed and hitting return further deletes any text added.

After using the CKEditor function insertText on an editor that already contains text, the CKEditor seems to go into a "Read Only" type mode.

Text can be read and selected but no typing is allowed. This can happen after insertText is used once, but happens more frequently when it is used several times.

Issue is reproducable with Chrome/31.0.1627.0, Firefox 23.0, MSIE10

We're unable to nest multiple spans using languages plugin

1. open any sample with CKEditor languages plugin enabled (i.e. samples/replacebyclass.html)
2. Replace content with following HTML: <p>This is sample code.</p>
3. Select sample substring and apply French language (by clicking chinese icon at toolbar, and selecting proper lang).
4. Select is sample code substring and apply Spanish language.

Expected result:
Produced source code: <p>This <span dir="ltr" lang="es">is <span dir="ltr" lang="fr">sample</span> code</span>.</p>

Current result:
Paragraph with nested spans: <p>This <span dir="ltr" lang="es">is sample code</span>.</p>

additional info:

1. Currently spans are created with CKEDITOR.style object being passed to CKEDITOR.editor.applyStyle()

Referring to: ​http://dev.ckeditor.com/ticket/10659#comment:8

1. Use replacebycode sample.
2. Set HTML

   <p><b>Apollo 11</b> was the spaceflight that landed the first humans.</p>
   

3. Set caret so it is still bold

   Apollo 11^ was…
   

4. Click remove format.
5. Type a few words.
6. ENTER.
7. For unknown reason, typing bold in the new line:

   <p><b>Apollo 11</b> cow says moo</p>
   
   <p><b>...</b> was the spaceflight that landed the first humans.</p>
   

I'm able to reproduce it since 3.6.6.1 in Chrome, Firefox and Safari (Mac).

Kudos to Anna and Olek.

When there is an anchor in the content, CKEditor requests the following image: /ckcke_contents_ltr0421/full/plugins/link/images/anchor.png?t=D8AD, assuming that CKEditor is located in "/ck 421/full/"on the server.

Note the weird path in the URL: /ckcke_contents_ltr0421/

Confirmed in 4.2.1 and 4.3 Beta. Did not check earlier versions.

Currently nested editables can be only initialized on elements included in the CKEDITO.dtd.$editable hash which includes those which should be "safe". However, it would be nice to increase number of allowed elements, especially with inline ones.

The workaround for now, if someone wants to try other elements, is to extend CKEDITOR.dtd.$editable object has early as possible.

Following the discussion ​https://dev.ckeditor.com/ticket/10835#comment:5 suggesting that we may may want to improve UX by putting some kind of an outline to the image, I open this ticket for research purposes and general brainstorming.

1. open Firefox,
2. go to ​http://ckeditor.dev/plugins/mathjax/samples/mathjax.html
3. put cursor after a widget (ex. after "is an example of an inline equation"),
4. press and hold left arrow button on your keyboard,

You can not move cursor before widget. This bug could be reproduce with any inline widget.

1. Open replacebyclass sample.
2. Place caret in table cell.
3. Press "option key" or click right mouse button to open context menu.
4. Using keyboard navigate to Cell -> Merge cells (which is disabled).
5. Press enter or click that option.

General problem - nothing should happen IMO when choosing disabled option.

Browser specific:

• IE: focus is completely lost - I'm unable to close the context menu or navigate in it.
• Chrome: focus is lost (at least I think so, because none option is focused), but everything still works.

1. Open IE10 or IE9
2. Go to inlinebycode.html sample
3. Go to templates.
4. Select 'Text and Table' template and insert in.
5. Right click on table cell and select Row -> Delete Rows

SCRIPT16389: Incorrect function.
 
inlinebycode.html, line 46 character 5

Currently widget may have only block editables. Support for inline ones would be interesting.

Note: there's a workaround if one wants to initialize inline editable - CKEDITOR.dtd.$editable has to be extended with name of that element.

Includes: #10973

since: 4.3 (didn't check earlier) until major

Firefox exclusive: pressing home/end key can put caret outside widget.

1. open any sample with image2 plugin (i.e. plugins/image2/samples/image2.html)
2. put caret inside first image caption
3. CTRL + a to select all
4. click on remove formatting button
5. press home key

Expected result:
Caret should collapse at the begining of previous selection.

Current result:
Caret goes outside of widget.

additional info:

1. When pressed home it places itself right before figure[class="caption"].

1. Open mathjax sample.
2. Set data to: <p>foo</p><p>bar <span class="math-tex">\(\TeX\)</span> bom</p>
3. Place caret at the beginning of 2nd line.
4. Press backspace. Widget and "bom" disappear.

• Blink bug report: ​https://code.google.com/p/chromium/issues/detail?id=306970
• Webkit bug report: ​https://bugs.webkit.org/show_bug.cgi?id=122748
• Extends the whole range of broken backspace/delete keys behaviours on Webkit/Blink: #9998.

• Insert table (3x3)
• Split left-middle cell horizontally
• Try to delete last column

Column is being removed but console error occurs.

Uncaught TypeError: Cannot read property 'ownerDocument' of undefined

Every nested editable which has allowed content rules defined has its filter instance. These instances are stored in nested editable instances, which most likely are correctly garbage collected. But filter instances are also stored in CKEDITOR.filter.instances and they are kept there forever.

We could have filter.destroy() method removing instance from the instances hash and doing other cleanup if necessary. Then we could destroy filters when destroying widgets.

1. Open Chrome,
2. Open New Image plugin sample,
3. Click on nested editable ("Roll out of Saturn V"),
4. Click on browser url bar,
5. Click again on nested editable.

Expected:

• editable has focus (blue outline), only accepted options are available.

Actual:

• editable haven't got focus (no blue outline), all buttons are available.

There are list of blocks and objects names defined in core/style.js. CKEDITOR.dtd should be reused there.

This is the continuation of ticket #10610.

There are two methods of adding iframedialog to editor:

1. CKEDITOR.dialog.addIframe method which is used when you only want to have iframe in dialog. The height of iframe (or rather wrapping div) was fixed in #10610.

2. There is also possibility to add iframe to dialog (sample code below).This method is used when you want to have something more in dialog except for iframe. Furthermore this method isn't fixed by #10610. It works when you define width and height in pixels but doesn't when you define % for iframe dimentions.

   ontents :
                          [
                             {
                                id : 'iframe',
                                label : 'some label...',
                                expand : true,
                                elements :
                                      [
                                         {
                                            type : 'iframe',                                       
   

To summarize: adding iframe as contents and setting height to 100% will result in small iframe.

Why this is happening: Div surrounding iframe has height auto and all elements inside it (when you define % for iframe) are % so the wrapping div will never get dialog height in this case.
Please go to: ckeditor4\plugins\dialog\plugin.js
Line 1039
In CKE 4.x this line is style: contents.style || 'width: 100%;' while in 3.x this was style: contents.style || 'width: 100%;height:100%;'. Bringing back height fixes this issue.

Ticket #10610 didn't involve fixing dialog plugin but iframedialog plugin. As discussed with @fredck, fix from #10610 did its job in 50%. It should be checked why doesn't it work for second case and if something can be done about it.

I’m attaching sample plugin for testing.

Extracted from: #11024. Related to: #9929.

There's WebKit&Blink bug:

• ​​https://bugs.webkit.org/show_bug.cgi?id=123163
• ​​https://code.google.com/p/chromium/issues/detail?id=310149

If it won't be fixed in browsers we should take care of this when we'll be implementing custom delete/backspace support.

So "  " and "  " should result in normal space after deleting any of them.

1. Open MathJax sample.
2. Select some text containing widget (or just widget).
3. Create link.
4. Click widget - after a while page is redirected.

Reproduced on IE9, but most likely concerns also other IEs.

1. Open image2 sample.
2. Place caret in nested editable.
3. Create link.
4. Caret is moved the the beginning of main editable.

Seleciton is placed inside nested editable. Instead, widget should be focused.

Widget reinit/recreate procedure should be rethought.

There's no way currently to reinitialize in a lightweight manner widget to which we lost references. It has to pass through entire process of setting attributes, classes, data, etc. What we need is only - rebinding listeners and initial widget#data.

Follow up for #10906.

When clicking below body, selection should be placed right above the cursor. Now it's placed in the last position or at the beginning.

• open Image2 plugin (plugins/image2/samples/image2.html),
• edit one of images to remove caption (reproducible only for inline widgets)
• drag image,
• use scroll on your mouse.

Mouse pointer change and browser does not response.

1. Open attached sample.
2. Place caret in nested editable.
3. Click widget.

Toolbar disappears.

Follow up for #11082.

1. Open image2 sample.
2. Select widget.
3. Click copy/cut button and accept security alert.

There's a big chance that selection was lost and widget wasn't copied.

Test /dt/core/dom/range/enlarge.html#test_enlarge_element12 fails in latest Safari 7.0 that comes with OSX 10.9. It's also reproducible in Chrome 37 (see #12221).

The root of the problem is the following condition: ​https://github.com/ckeditor/ckeditor-dev/blob/major/core/dom/range.js#L1039

In this case sibling is empty <b></b> (<p>Test <i><b></b>[Enlarge]</i></p>). Unlike previous versions, Safari 7 considers sibling.$.offsetWidth to be 1 at that point, while in other browsers it is 0. So the conclusion is that empty elements may have some width, which seems to be a regression in browser's engine.

That particular test fails since CKeditor 4.0 in Safari 7 which makes it clear that we're facing Safari regression.

Related bug in Chrome: #12221.

1. open Chrome.
2. open "Mathematical Formulas" sample.
3. Select any widget.
4. Copy (Ctrl+C).
5. Click in the middle of the first paragraph.
6. Paste widget (Ctrl+V).
7. Apply numbered list on this paragraph.
8. Change paragraph type to bulleted list.

Result:

<span tabindex="-1" contenteditable="false" data-cke-widget-wrapper="1" data-cke-filter="off" class="cke_widget_wrapper cke_widget_inline cke_widget_selected" data-cke-display-name="math" data-cke-widget-id="6">
	<span class="math-tex cke_widget_element" data-cke-survive="1" data-cke-widget-data="{&quot;math&quot;:&quot;\\(k\\)&quot;}" data-cke-widget-keep-attr="0" data-widget="mathjax" style="display: inline-block;">
		<iframe style="border: 0px; width: 12px; height: 19px; display: inline; vertical-align: middle;" scrolling="no" frameborder="0" allowtransparency="true" src="javascript:void(0)"></iframe>
		<iframe style="border: 0px; width: 12px; height: 19px; display: inline; vertical-align: middle;" scrolling="no" frameborder="0" allowtransparency="true" src="javascript:void(0)"></iframe>
	</span>
	<img src="data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw%3D%3D" class="cke_reset cke_widget_mask">
	<span class="cke_reset cke_widget_drag_handler_container" style="background-color: rgba(220, 220, 220, 0.498039); background-image: url(http://presets.ckeditor.dev/4.3/full-all/ckeditor/plugins/widget/images/handle.png); top: -15px; left: 0px; background-position: initial initial; background-repeat: initial initial;">
		<img class="cke_reset cke_widget_drag_handler" data-cke-widget-drag-handler="1" src="data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw%3D%3D" width="15" title="Click and drag to move" height="15" draggable="true">
	</span>
	<img src="data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw%3D%3D" class="cke_reset cke_widget_mask">
	<span class="cke_reset cke_widget_drag_handler_container" style="background-color: rgba(220, 220, 220, 0.498039); background-image: url(http://presets.ckeditor.dev/4.3/full-all/ckeditor/plugins/widget/images/handle.png); top: -15px; left: 0px; background-position: initial initial; background-repeat: initial initial;">
		<img class="cke_reset cke_widget_drag_handler" data-cke-widget-drag-handler="1" src="data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw%3D%3D" width="15" title="Click and drag to move" height="15" draggable="true">
	</span>
</span>

The same happens with placehoder plugin.

since: 4.0 until major

This issue also appears in widgets content editables.

1. open any sample with CKEditor (i.e. samples/replacebyclass.html)
2. use following source:

   <p>dsadasd <a href="http://aasd">asdsd</a> dassd</p>
   

3. switch back to wysiwyg mode
4. ctrl+a (select all)
5. click once inside link text, to place caret as follows:

   dsadasd as^dsd dassd
   

Expected result:
Following elementspath: body p a

Current result:
Elementspath without a element: body p

Second case:
Steps 1-4 as in case above

5. click once text after link, to place caret as follows:

   dsadasd asdsd das^sd
   

... and now elementspath shows body p a but it should not.

additional info:

1. issue does not appear after first click
2. issue was not present in 3.6.6.1 (tested with ie10), but please, double check me here
3. present in IE9, IE10, IE11 - i didnt check ie8