Custom Query

#9535 ticket is for v4, this enter key bug also affects v3, even worse it breaks both enter and shift-enter.

There exists number of internal plugins that are originally planted in v3 for better isolation, but in fact they'd be merely used by their "parent". We shall consider merge those into their parents for the following benefits:

1. Reduce the number of plugins to maintain:
2. Avoid confusing in the repository

The following list to be considered: ( -> indicates merge direction):

• listblock -> richcombo
• floatpanel -> panel
• dialogui -> dialog

There's no doc string for CKEDITOR.dialog.validate and ​its methods. At the moment it's a ghost stuff.

The feature concerns make the menu button hybrid, to behavior in the following ways:

• Click on button arrow opens up the menu (what we have today)
• Click on button icon to execute a command
• Makes the button remember the last option selected on menu.

With this basis we'll be able to group several toolbar buttons into one, good for:

• Usability
• Compact Toolbar

We need a nice iconset + guidelines for our new addon repo.

Now it's hard to find "how to contribute". I couldn't find this in docs and on ckeditor/ckeditor-dev, so in places where developers look for that.

1. Open any sample.
2. Change format of any block to pre-formatted.
3. Place caret anywhere in that block.
4. Press enter.
5. Caret remained in first line.
6. Type.
7. Caret was moved and text was inserted in next line.

Rationale - this event is used by two plugins (and after proposed change, by 3).

​http://dev.ckeditor.com/ticket/9706#comment:4

Again we were close to miss some important error because it was thrown in silent try-catch (this time in selectionChange listener).

We should review all try-catches in code and:

1. if that's a try-catch that covers only one critical line of native code that can throw an error which we cannot handle differntly, then it's ok.
2. all other try-catches should be:
   1. removed (may be unsafe, because we'd have to test what'd be the impact).
   2. logged - we need logs (at least in DEV mode - we can introduce CKEDITOR.DEV flag with %REMOVE_LINE% annotation) of caught errors. Now it'd be unsafe to unwrap e.g. selectionChange listeners, so at least we should know about what was caught.

​`.cke_mixed_dir_content` is extensively used by release packages but there's no other occurrence in dev code (except toolbar), which makes it look obsolete.

It should definitely have a word or two of description.

1. Open any sample.
2. Insert image.
3. Select that image.
4. Click align left.
5. Image is aligned left, but align left button isn't active.
6. Blur image.
7. Select image again.
8. Align left button is now active.

The same happens for align right.

Expected: align buttons' states should be updated after changing image alignment.

Continuation of #9800 (especially ​http://dev.ckeditor.com/ticket/9800#comment:3)

• It should not cause reflows on every mouse move. This is very expensive, especially when user moves cursor very fast. There are lags on FF that may be caused by that.
• On Webkit sometimes it misses mouseup and is still resizing with mouse button released.
• Code of this plugin can be simplified and shortened.

Pull request: ​https://github.com/ckeditor/ckeditor-dev/pull/9

This feature would be very valuable for CMSes.

1. Open any sample.
2. Insert table (with cell padding and cell spacing set to 0).
3. Place caret inside table cell.
4. Insert next table (with cell padding and cell spacing set to 0).

• Expected: Nested table fills entire outer table cell.
• Actual: There's free space at the bottom of table cell. It's caused by bogus <br>.

This behaviour was helpful in v3, but in v4 we can use magicline to place caret after the table.

Perhaps more cases may be find in which we create unnecessary paragraphs/bogus brs to allow caret positioning.

At least code refactorization can be done (without changing the logic), since there are many things like:

node.getAscendant( 'td' ) || node.getAscendant( 'th' );
//which is equal to:
node.getAscendant( {td: 1, th: 1} );

We could save lots of bytes by optimizing this code.

If rendered as below contenteditable will be set to false automatically (I guess by ckeditor). However if I set the div #my-id as visible with javascript and at the same time set contenteditable back to true the editor will still be in readonly mode. (Sometimes I can for some reason use copy-paste to enter text to the editor but I can't write regularly with the keyboard.)

Sent by the server: <div id="my-id" style="display:none;">

<h3 contenteditable="true">Header</h3>

</div>

After page render by the browser (it changed contenteditable to false): <div id="my-id" style="display:none;">

<h3 contenteditable="false" class="ck-editable cke_editable cke_editable_inline cke_contents_ltr cke_focus"" spellcheck="false">Header</h3>

</div>

After my custom javascript (removes display:none & sets h3 tag to contenteditable="true"): <div id="my-id" style="display:none;">

<h3 contenteditable="true" class="ck-editable cke_editable cke_editable_inline cke_contents_ltr cke_focus"" spellcheck="false">Header</h3>

</div>

Issue is caused by:

• Webkit bug: ​https://bugs.webkit.org/show_bug.cgi?id=133371
• Blink bug: ​https://code.google.com/p/chromium/issues/detail?id=313082

Workaround:

var ck = CKEDITOR.inline(element);
ck.on( 'instanceReady', function( ev ) {
     var editor = ev.editor;
     editor.setReadOnly( false );
});

On Mac, ALT+F10 and ALT+F11 open the sound settings menu instead of the anticipated CKEditor accessibility features.
Tested on Macs with OS X Mountain Lion (10.8.2) and standard Apple keyboards (where F10 and F11 control the sound).

Most likely, the following ​https://github.com/ckeditor/ckeditor-dev/blob/master/plugins/magicline/plugin.js#L1463-L1514 code can be replaced/improved/shortened with element.getClientRect() method.

There's also a possibility of performance gain since getClientRect directly refers to native DOM getBoundingClientRect.

ALT+- keystroke doesn't work for me on FF (Linux and Win). In toolbar plugin keystroke is added for:

CKEDITOR.ALT + ( CKEDITOR.env.ie || CKEDITOR.env.webkit ? 189 : 109 )

This, for some reason works on v3, but on v4 doesn't, because ALT+- is ALT+173.

Currently events implementation accepts one listener function attached only once to one event on one object. When it's attached twice or more times (even with different context) it's ignored (or overwrite previous one).

To avoid issues like ​http://dev.ckeditor.com/ticket/9800#comment:11 events system should notify when listener is added second time. Perhaps we'll also find more issues like #9800, which will need to be fixed.

Harder way - we can remove this limitation from events system, by adding context as a next key. However:

• we would also need to change signature of event#removeListener (it'd need to accept context)
• there still will be a limitation about which developer should be notified by logged errors.

Some browsers let the floating space with toolbars overflow out of the viewport (Chrome). Some of them (FF, IEs) scale down the toolbar to fit it into viewport.

We must decide which method is correct and make this behavior consistent since sometimes it looks bad and may be confusing for users.

We do several inline elements fixing that are found orphan inside body. This was true for <br> as well, until we reverted a fix that was causing #9167.

Because of that, I've commented out a test made for that case form dt/core/htmlparser/fragment.html, test name "test_parser_13".

It is still unclear for me the cases for this fix, but considering that we were used to do so, we should keep doing it.

I'm just unsure if this is necessary.

1. Resize browser window so it's lower than 300px.
2. Open replacebyclass sample.
3. Scroll down.
4. Open image dialog.
5. Try to move it by dragging header.
6. It will stick to upper viewport border. It's impossible to move it lower.

Extracted from #8888.

In v4 we support latest FF and latest FF3.6.*. However, in code I found many outdated fragments.

What should be done:

• env.isCompatible update.
• env.cssClass update (Gecko 1.8 means FF<3).
• Fixes targeted for unsupported versions of Gecko should be removed.
• #9716 should be verified for v4.

There is room the enhance the context checking we do for several toolbar buttons. While the current approach is correct, it can be optimized to better fit user's intentions, helping on the UI usability.

One good example for that is related to object selections. There is no much sense on having inline styles, like bold, enabled when an image is selected.

Let's open a discussion and analise all possible cases first.

In this case it allows to insert space between divs by ctrl+shift+3, but it shouldn't. Accessing that space should be possible only from paragraph p1.

<div>div1</div>

<div>
  <p>p1</p>
  <p>p2^</p>
</div>

The "OK" button looks a bit bad in RTL environment.

Happens at least since 3.5, did not try earlier versions.

The documentation for ​uiColor suggests using a color name for uiColor. It works fine in Kama skin, but does not work (properly) in Moono.

It looks like the provided color name is used somehow, but the the buttons are black.

The attached screenshots presents the result of

config.uiColor = 'Gold';

Currently editor inline has no collapse toolbar button because there was no real use case for it.

There is one use case that depends on other feature being implemented. Feature #7280 "switch toolbar at runtime" talks about changing toolbar definitions when command is executed - collapseToolbar or other like maximize toolbar button is pressed.

What CKEditor should do is provide ability to change toolbar at runtime and provide some hooks (events) when button is pressed. That way, users could create behaviour they want with any or almost any plugin.

Agreed that implementing this button so that some users could use it for their custom needs is an edge case but think what is the better place to do so than this little and nice looking button (better then button outside of editor) :)
Besides there might be other use cases that users will come up with.

1. Open any sample.
2. Insert textarea into editor.
3. Right click on it.

JS error is thrown:

Error: Permission denied to access property 'nodeType' @ core/dom/node.js:25

Context menu usually doesn't show up.

1. Open autogrow sample.
2. Add paragraphs so editor is higher than viewport.
3. Maximize editor.
4. There's no scrollbar.

1. Visit ​http://ckeditor4.t/ckeditor/samples/plugins/enterkey/enterkey.html
2. Set enterMode to BR
3. Play with Ctrl+Alt+[ or ]
4. See Object doesn't support property or method 'setAttributes'

This is because the focus space is not an element anymore (BR mode), so it cannot have data-cke-magicline-hot attribute set.

Tested in IE9. Possibly also in other browsers.

1. Open UIColor plugin sample /plugins/uicolor/samples/uicolor.html
2. There's no UIColor button.
3. Removing inline editor (which isn't supported in QM) doesn't help.

It works well e.g. inside table. But when it should be displayed with width:100% the right part isn't visible.

1. Open any dialog with native HTML select combo box (i.e. link dialog).
2. Open "protocol" select.
3. Press ESC.
4. • Chrome: Select collapsed, dialog visible.
   • Others: Dialog closed.

This behavior must be consistent.

1. Open ​http://ckeditor4.t/ckeditor/samples/plugins/uicolor/uicolor.html
2. Focus inline editor.
3. Having the floating toolbar visible, start resizing the framed instance above.
4. Floating space is visible (but shouldn't), it remains in original position.
5. Blur/focus/blur/focus inline instance to see that toolbar position is permanently broken.

1. Write two paragraphs.
2. Indent second one.
3. Select both of them.
4. Click list button.
5. Second list item is intended, but it's not a nested list item.
6. Try to outdent it - it is transformed back to paragraph.

In my opinion when paragraph is indented when creating list it should become a nested list item. However, that won't be possible for first paragraph, because it can't become a nested list (at least when indenting first item of a list).

Different solution may be found, but it should be consistent with how indent buttons work for lists and what's possible using them.

I can't understand why this event is called instanceReady. We have editor#loaded and CKEDITOR#instanceLoaded (it isn't documented, but it exists ;> #9910), so together with CKEDITOR#instanceReady we should have editor#ready.

OFC we need backward compat, so we can have both - deprecated instanceReady and ready for some time and remove it after 1-2 years.

​http://docs.cksource.com/CKEditor_3.x/Users_Guide/Keyboard_Shortcuts

How to reproduce:

1. Open enter key sample and switch to BR mode.
2. Use the developer console to set the editor data

   CKEDITOR.instances.editor1.setData('<iframe></iframe>');
   

3. Set the cursor after the iframe and press enter to make a newline
4. Press backspace to delete an iframe

JS error is thrown:
Message: Can't get property "remove": object is empty or undefined
Line: 171
URI: /ckeditor/plugins/wysiwygarea/plugin.js

NOTE: IE8 has its own problems defined here #8446. Problem can be reproduced from CKEditor 4.0. In CKEditor 4 beta inserting iframe caused another error - insufficient privileges.

To reproduce:

1. Open enter key sample and set enter mode BR.
2. Press New Page Toolbar button

Result: JS error is thrown
Message: Unspecified error
Line: 1012
URI: ckeditor/core/selection.js

Problem can be reproduced in IE10 from CKEditor 4.0

Reported on the forum: ​http://ckeditor.com/forums/CKEditor/Delete-key-not-working-if-at-end-of-line-past-a-space

Steps to reproduce:

1. Open the ​standard sample.
2. Place cursor at the end of the line (but not end of paragraph), after the trailing space.
3. Use Del to delete text.

Expected result: text from the next line is deleted.

Actual result: nothing happens.

Placing the cursor before the space works as expected and the text is deleted.

IE, Chrome do not seem to be affected. In Opera it seems like there is no space at the end of the line - the cursor always appears after the last character and deletion works as expected.

The elements path has been disabled on inline editing as a fix for #9847.

That fix was way too simplistic, not really solving the problem. It is totally ok to have elements path available for inline editing if a bottom space is made available to the editor instance. The shared spaces plugin showcases this in its sample, for example.

getLast, getNext, isEmpty, isBlockBoundary, insertAfter, insertBefore, append, removeFromParent, getNodeIndex.

Thanks to that will be able to test them, so tests should be written.

Descriptive summary :

It seems that it is impossible to leave many flow elements. Magic line simply doesn’t show when you hover cursor below/ above or between them.

This of course makes it impossible to add new content outside of these elements.

These missing flow elements are:

• section elements: nav, section, article, aside, header, footer, hgroup
• Grouping elements: address
• Interactive elements: details (supported only in Chrome).
• Form elements: fieldset
• Interactive elements figure
• Embedded content: audio, video

Menu isn’t supported in any browser so I wasn’t able to check it.

Rest of flow elements from this list ​http://www.w3.org/TR/html-markup/common-models.html either don’t need magic line or is supported by this plugin.

Reported on the forum: ​http://ckeditor.com/comment/123583#comment-123583

I noticed my site was becoming slow and less responsive recently and after some profiling I traced it to this plugin. It seems that anywhere the mouse is moved triggers a mouseout event so basically the entire time the user is using a page in my application with this plugin it was causing it to be less responsive.

I traced it to this line of code inside the plugin.js file of magicline. I am using v4 of ckeditor with the div based editor.

Hide the box on mouseout if mouse leaves document.

editable.attachListener( that.inInlineMode ? doc : doc.getWindow().getFrame(), 'mouseout', function( event ) {

See attached profile results. Notice I ran it for just 2.1 seconds and the top 7 calls were running for 1.7 - 1.9s a piece which explains why it was so bogged down. These results are probably slightly misleading as well because as I move my mouse in and out of the page to click the Profiler in Firebug it would stop triggering mouse out events which means realistically as long as the user has their mouse moving on the page cycles are being consumed the entire time for no reason.

Currently enabling external plugins is a two step process. First one have to call CKEDITOR.plugins.addExternal(), then add the plugin to config.extraPlugins.

It would be cool if there was an easier way to do this, without searching in the documentation how to point CKEditor to a plugin in a different folder.

The current string sytax could be preserved, plus we could allow users to specify an object with plugin => url:

config.extraPlugins = {
  plugin1 : url1,
  plugin2 : url2
}

If one wants to mix external and non-external plugins, something like this could do the trick:

config.extraPlugins = {
  plugin1 : url1,
  plugin2 : url2,
  plugin3 : '', // equals config.extraPlugins = 'plugin3'
}

I just spent a couple of minutes on trying to find this article for one user and I did it just because I remembered that something like this existed.

How about:

1. Promoting it somewhere on the front page of docs.ckeditor.com

2. Putting at the top of CHANGES.md something like this:

The list of relevant changes can be found in the ​API Changes page of the CKEditor 4 documentation.

?

I do not think it still makes a lot of sense to keep the _translationstatus.txt text files in CKEditor lang folders.

A much better overview of current translation status (with up-to-date stats) can be checked online @ ​CKEditor project page @ Transifex

We still can have a text file in the lang folder (e.g. readme.md), but with an explanation how one can contribute and with a direct link to CKEditor UI translation center, plus eventually a link to documentation about how one can contribute.

I guess providing such a file is not a requirement though.

1. Paste in below code in replacebycode sample

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

2. Run sample and Press Enter
3. keydown listener doesn't catch it.

Problem can be reproduced in all browsers from CKEditor 4 beta

There are two events "afterUndo" and "afterRedo" that seem like good ways to be notified about when an undo/redo operation is performed but they are trickier to use because they aren't fired on the editor but on the commands themselves:

			var undoCommand = editor.addCommand( 'undo',
				{
					exec : function()
					{
						if ( undoManager.undo() )
						{
							editor.selectionChange();
							this.fire( 'afterUndo' );
						}
					},
					state : CKEDITOR.TRISTATE_DISABLED,
					canUndo : false
				});

			var redoCommand = editor.addCommand( 'redo',
				{
					exec : function()
					{
						if ( undoManager.redo() )
						{
							editor.selectionChange();
							this.fire( 'afterRedo' );
						}
					},
					state : CKEDITOR.TRISTATE_DISABLED,
					canUndo : false
				});

if instead of "this.fire" the code is "editor.fire" then they can be used in a normal way.

I think that this is just a typo that no one has realized so far (after all these events aren't documented in any way)

I don't think that anyone is using the current events so it shouldn't be a problem to correct them.

I guess that you won't bother about fixing this in 3.6 so I'll create a patch just for 4.0

A request added at the community forum: ​http://ckeditor.com/comment/124098#comment-124098

Is there any way to integrate ckbuilder into a maven based build process?

Is there a chance to have the ckbuilder in maven central?

1. Open inlinebycode sample.
2. Without focusing editor first, click inside editor area, but not near the text, so editor is focused, but cursor isn't blinking.
3. Click list button.
4. Error is thrown.

Uncaught exception: TypeError: Cannot convert 'path' to object

Error thrown at line 70, column 2 in <anonymous function: refresh>(editor, path) in http://localhost/cksource/ckeditor-dev/core/command.js:
    if ( this.context && !path.isContextFor( this.context ) )
called from line 416, column 3 in <anonymous function: exec>(editor) in http://localhost/cksource/ckeditor-dev/plugins/list/plugin.js:
    this.refresh(editor, editor.elementPath());
called via Function.prototype.call() from line 52, column 2 in <anonymous function: exec>(data) in http://localhost/cksource/ckeditor-dev/core/command.js:
    return ( commandDefinition.exec.call( this, editor, data ) !== false );
called from line 531, column 5 in <anonymous function: execCommand>(commandName, data) in http://localhost/cksource/ckeditor-dev/core/editor.js:
    eventData.returnValue = command.exec(eventData.commandData);
called from line 79, column 4 in <anonymous function: click>(editor) in http://localhost/cksource/ckeditor-dev/plugins/button/plugin.js:
    editor.execCommand( definition.command );
called from line 135, column 5 in <anonymous function: execute>() in http://localhost/cksource/ckeditor-dev/plugins/button/plugin.js:
    this.button.click( editor );
called from line 182, column 4 in <anonymous function>() in http://localhost/cksource/ckeditor-dev/plugins/button/plugin.js:
    instance.execute();
called via Function.prototype.apply() from line 569, column 4 in <anonymous function: addFunction>() in http://localhost/cksource/ckeditor-dev/core/tools.js:
    return fn.apply(scope || this, arguments);
called via Function.prototype.apply() from line 595, column 3 in <anonymous function: callFunction>(ref) in http://localhost/cksource/ckeditor-dev/core/tools.js:
    return fn && fn.apply(window, Array.prototype.slice.call(arguments, 1));
called from line 1, column 0 in <anonymous function>(event) in http://localhost/cksource/ckeditor-dev/samples/inlinebycode.html:
    CKEDITOR.tools.callFunction(121, this);

1. Open ​http://ckeditor4.t/ckeditor/samples/replacebycode.html
2. Scroll to the table (on the right).
3. Put caret in some cell.
4. Use elementspath, click TR.
5. Insert HR via toolbar.
6. Infinite loop. Window is broken.

Tested in Chrome 25, IE10.

It it impossible to build CKEditor after this change: ​a2136ce (native is a reserved keyword). I remember that it happened at least once in the past. We renamed the "native" variable to "nativ".

After a quick research it turned out we may get rid of this issue forever by using this piece of code:

options.setLanguageIn( CompilerOptions.LanguageMode.ECMASCRIPT5 );

native was a future reserved word in ECMAScript v3. Closure Compiler follows ES4, which also lists native as a reserved keyword.

However, I believe it will be quite unsafe to switch CC to ES5 mode at this moment, because this time we may not notice code that will be incompatible with IE7.

It is first time called in editable's constructor, second in onDomReady inside wysiwygarea plugin.

This may not be a wrong behaviour, though it looks like one. We should investigate whether after the first call every changes (new listeners, etc) are cleaned up before second call. This maybe happen thanks to clean up done by setData which is done in onLoad function inside 'wysiwyg' mode (not class) constructor.

If everything is ok, appropriate docs should be written to avoid confusion in the future. Why editable#setup has to be called for the first time and why for the second time?

1. Open inlineall sample.
2. Focus one of editors.
3. Apply marker style from stylescombo.
4. Style is applied, but it's not visible in the inline editor contents.

It works on themed editor, because marker style is defined in contents.css.

Other TC:

1. Open inlineall sample.
2. Open format combo.
3. Apply header 1 style.
4. Open combo again and compare how header 1 looks in combo and in contents of the editor. They have different font styles.

The new sourcedialog plugin introduced a new button name for a feature that already exists - editing source code. I think it is wrong because of various reasons.

1. Do not use different button names

(i) Noone would like to have enabled both "Source" buttons in the toolbar at the same time. The only purpose of both plugins is to edit source code (that's why even the buttons looks the same).

Why user may want to use both plugins? Let's look at the case of Drupal: there is a framed editor in the administration area and inline editor in another place. So it needs both plugins (unless the sourcedialog will be used in each case, however some may prefer the sourcearea plugin and use sourcedialog just as a fallback solution.

(ii) Once user realize that he has two buttons in some samples (after downloading a custom package), he'll have to start digging how to change the toolbar configuration to get rid of one button. And then, deal everywhere with toolbar configurations or removePlugins/extraPlugins and so on.

* Unless we configure online builder to allow adding just one plugin of this kind.

2. sourcedialog could be shipped in std/full package

Currently, because of a "toolbar conflict" between both plugins, we cannot have both enabled in default packages (at least without adding code to other samples to handle both plugins at once). If we ensure that both plugins can be enabled at once and that duplicated buttons will not appear, that would be cool, because for example the inline/sharedspace samples could show this button.

There is so many samples, that it is still hard to say whether CKEditor supports source editing in inline mode, by looking at promoted inline samples at the top where the "Source" button is missing.

This is the main reason why I think it would be better if plugins could somehow cooperate, to be able to use source editing in inline mode without any extra effort. If enabling the "Source" button in inline environment would require from user 0 additional steps that would be quite awesome.

3. sourcedialog for inline editing sourcearea for framed mode?

If both plugins are enabled, we could make the plugins a bit more smart: let the sourcearea plugin work in framed environment and enable the source dialog plugin in environment not supported by sourcearea. Again, a single button name would be used for the toolbar configuration.

Found by Olek. It looks like the docprops is missing colordialog entry in the "requires" property. The "Choose" buttons in "Design" tab are supposed to launch colordialog.

Continuation of ticket #7943.

It has been fixed in CKE 3.x but can be reproduced in 4.x branch in both skins.

To reproduce:
Add styles on page:

<style type="text/css">
    label,select,.ui-select-menu { float: left; margin-right: 10px; font-size:1.3em; height:26px; line-height:26px; font-size:1em; }
</style>

Open dialog - labels are floated.

To reproduce:

1. Open enter key sample and set mode to BR
2. Press new page button
3. Insert two div containers
4. You should have div div p in elements path now - try clicking inside content area

Result: Elements path shows only body like there is nothing in editor.

In 4.0 beta - You had to source and back to see the code again plus magic line above divs.

From 4.0 - You also have to switch to source and back to see the code again but magic line behaves different.
It shows up in first line and once you click on it, elements path shows only body. This gives you false impression that whole code wasn't created. Since cursor is now in correct place you may want to create your containers again. If you do that and switch to source you will get two sets of divs.
First set for some reason gets hidden.

Problem can be reproduced only in Webkit.

1. Create new table with default width 500.
2. Switch to wysiwyg mode and resize it with FF native handles.
3. Right click on the table and select Table properties.

Result: Width has no value assigned.

This is happening because when using Firefox native resize handles, Firefox operates on attributes while CKEditor operates on styles what results in two widths (#9287).
Issue #9287 no longer occurs in CKE 4.1 RC but one does and can be reproduced from CKEditor 4.0 in Firefox browser.

There are two main input sources:

• data loaded to editor by setData(),
• and html inserted into editor when pasting or directly by insertHtml().

Currently input data which comes from both of these sources is processed by the same data processor - htmlDataProcessor.

However, the idea of data processors is to be able to handle different data formats - e.g. markdown and bbcode.

Because of the current architecture this is clearly impossible to replace editor.dataProcessor with e.g. markdownDataProcessor, because pasted data will be processed as... a markdown input.

Therefore I'm proposing to introduce second property - the editor.htmlProcessor. There will be two properties now:

• editor.dataProcessor - used for 1st kind of input (setData()),
• editor.htmlProcessor - used for 2nd kind of input (pasted, inserted HTML).

This is very simple fix - we need to set editor.htmlProcessor = editor.dataProcessor and use htmlProcessor instead of dataProcessor in editable.setData.

If one want to handle different input format he has to replace editor.dataProcessor with his own dataProcessor, what will not break pasting/inserting HTML like it does now.

Steps To Recreate:

1. Open replacebycode sample
2. Switch to source and pase:

   <p>This is an example [<a href="http://bbc.co.uk">click</a>] of linked text.</p>
   

3. Copy the whole line and paste 4 or so times into the page.
4. Click the Find/Replace button, and select the replace tab.
5. In the "Find what:" type "[click]". Do not type anything into the "Replace with:" text box.
6. Click "Replace All".

Result: The find and replace tool only replaces one match when you choose "replace all".

1-5. The same as above

6. Click "Replace" - the text gets a highlight.
7. Click "Replace" again -- the text is replaced (with nothing).
8. Click Cancel.

Result: JS error os thrown: Message: TypeError: startNode is null
Line : 1469
URI: ckeditor4/core/dom/range.js

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

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

To reproduce:

1. Paste below code into source mode

   <ul style="list-style-type:square;">
   	<li>one</li>
   	<li>two
   	<ul>
   		<li>three</li>
   	</ul>
   	</li>
   </ul>
   

2. Switch to wysiwyg and apply style for list (from styles dropdown) to outer list.
3. Click on inner list and notice that list style is selected although inner list doesn't really have it.

I think the problem is checkActive method in core/styles.js which checks all elements from elements path for inline and object styles:

case CKEDITOR.STYLE_OBJECT:
case CKEDITOR.STYLE_INLINE:
	var elements = elementPath.elements;
	for ( var i = 0, element; i < elements.length; i++ ) {...

Based on #10187.

The only way to change base path is using GLOBAL variable - CKEDITOR_BASEPATH. After setting this value, CKEditor.basePath == CKEDITOR_BASEPATH and CKEDITOR.plugins.basePath == CKEDITOR_BASEPATH +'/plugins'.
Properties basePath and plugins.baePath are read-only and changing them will not have any result. If you look at the ticket #10187 you will see that not everyone knows that.

As discussed with @fredck I propose:

1. Marking them in docs as read-only values
2. Changing text for plugins.basePath from "The base directory containing all resources." to something like "Path to directory containing all plugins". First one may suggest that this is in fact path to CKEditor directory.

This code is executed multiple times when switching between modes. It is hard to predict whether this is safe or not, therefore it should be fixed.

	// Editor commands for accessing difficult focus spaces.
	editor.addCommand( 'accessPreviousSpace', accessFocusSpaceCmd( that ) );
	editor.addCommand( 'accessNextSpace', accessFocusSpaceCmd( that, true ) );

	editor.setKeystroke( [
		[ config.magicline_keystrokePrevious, 'accessPreviousSpace' ],
		[ config.magicline_keystrokeNext, 'accessNextSpace' ]
	] );

	// Revert magicline hot node on undo/redo.
	editor.on( 'loadSnapshot', function( event ) {
		var elements = doc.getElementsByTag( that.enterBehavior ),
			element;

		for ( var i = elements.count(); i--; ) {
			if ( ( element = elements.getItem( i ) ).hasAttribute( 'data-cke-magicline-hot' ) ) {
				// Restore hotNode
				that.hotNode = element;
				// Restore last access direction
				that.lastCmdDirection = element.getAttribute( 'data-cke-magicline-dir' ) === 'true' ? true : false;
				break;
			}
		}
	} );

<ol>
	<li>item1</li>
	<li>&nbsp;
	<ol>
		<li>item2</li>
	</ol>
	</li>
</ol>

Place caret at the beginning of second list item (nbsp) and press enter.

Result:

<ol>
	<li>^item1</li>
	<li>&nbsp;</li>
	<li>&nbsp;
	<ol>
		<li>item2</li>
	</ol>
	</li>
</ol>

Note that the caret was moved up to the item 1.

I was able to reproduce this on Chrome, but not on FF.

​http://docs.ckeditor.com/#!/api/CKEDITOR.dom.walker

It says that walker may split nodes and the examples shows such a case. However, neither unit tests nor my manual tests proved that.

Source: ​http://stackoverflow.com/questions/15613082/ckeditor-walker-get-selection-only

Some dialogs are still not compatible - not allowed fields are displayed.

Already compatible:

• image
• link
• div
• iframe
• flash

Incompatible:

• tabletools
• forms
• liststyle
• ?

Paste this HTML to the editor:

<table border="1" cellpadding="1" cellspacing="1" style="width:500px">
	<tbody>
		<tr>
			<td>
			<ul>
				<li>foo</li>
				<li>bar</li>
			</ul>
			</td>
			<td>OOO</td>
		</tr>
	</tbody>
</table>

Place caret after "bar". Press delete.

Expected: nothing happened

Actual: "OO" moved from second table cell to the first one and error on the console.

Reproducible on all browsers.

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]';
		}
	}
} );

1. Clear editor contents with new page
2. Press Bulleted list button
3. Type test
4. Press Shift+Enter
5. Press Enter
6. Repeat steps 3-5 few times.
7. Press Ctrl+A and Ctrl+C
8. Clear editor contents with New Page command
9. Press Ctrl+V

Result: &nbsp; and br tags are lost thus new lines get removed.

Problem can be reproduced from CKEditor 3.5.3 rev [6624].

Other tickets caused by this revision: #8743, #8140

• Open source code view
• Insert the attached html code snippet
• Switch back to wysiwyg view
• Select all content
• Press 'Del' key

IE10 crashes, IE9 is fine. This is also reproducible with the current demo.

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.