IE Selected format not applied to typed text

[Satya Minnekanti]

To reproduce the defect

1. Open any sample except AJAX.

2. With out focus in Editor body click on Bold,Italic,Underline & Strike Through icons.

OR:

It can be reproduced also when focus is inside the editor. Place the cursor at the beginning of the paragraph. Click on Bold,Italic,Underline & Strike Through icons.

3. See that only last selected icon(Strike Through) shown as selected in the Tool bar.

4. Start typing the text

Expected Result:

Typed text should have Bold,Italic,Underline & Strike Through formats applied and Bold,Italic,Underline & Strike Through icons selected in the Tool bar.

Actual Result:

Typed text has only last selected format applied (Strike Through) and only last selected format option(Strike Through) shown as selected in the Tool bar. Even when we look at Element path bar or HTML Source only tag for Strike Through format is shown.

To reproduce the defect in AJAX Sample. Type some text save the page.open the Editor again and repeat the above steps

[Garry Yao]

Mark as low priority because of precondition "With out focus in Editor body".

[Garry Yao]

It affects only collapsed cursor at the start of non-empty block.

[Sa'ar Zac Elias]

Hit New Page, then Bold. JS error is thrown.

[Frederico Caldeira Knabben]

The filling char is something we should try to avoid. This is an ugly hack for WebKit, that I would love to have out of our codebase.

Maybe something simpler can be found for IE.

[Garry Yao]

It looks senseless of saying having it in webkit is less polluting to codebase then in IE, considering the fix is pre-limited on a few situation, it could almost been considered as a solution, unless you can propose a more robust fix.

[Frederico Caldeira Knabben]

Replying to garry.yao:

It looks senseless of saying having it in webkit is less polluting to codebase then in IE

Yes, if you're limited to the current state of things. The idea is that, as soon as WebKit fixes its issues, we'll have the chance to cleanup our code from this ugly hack. If we enlarge its usage to IE9 we'll have less chances to do so.

For now, I've opened an issue at Microsoft for this:
​https://connect.microsoft.com/IE/feedback/details/671206

Hopefully we'll have some feedback. I doubt, but let's wait a bit for it.

[Damian]

Replying to fredck:

For now, I've opened an issue at Microsoft for this:
​https://connect.microsoft.com/IE/feedback/details/671206

I am getting a Page Not Found error when following that link. Is there any way you could share the details of this defect report?

[Satya Minnekanti]

Replying to garry.yao:

@garry.yao could you please add the ticket that you logged with Micrrosaoft for this issue

[Frederico Caldeira Knabben]

Replying to damo:

Replying to fredck:

For now, I've opened an issue at Microsoft for this:
​https://connect.microsoft.com/IE/feedback/details/671206

I am getting a Page Not Found error when following that link. Is there any way you could share the details of this defect report?

That's the URL for it. I'm not sure it's visible only by me, but the "Access restriction" field is saying "public", so it should be visible.

Right now MS says "We were able to reproduce the issue and are investigating it", so there is some hope.

[Jakub Ś]

I have checked this problem in IE6-10 and it seems that when cursor is located at the start of plain text or paragraph/div with text (doesn't matter if you use mouse or bold button to put it there) only the last clicked button will work and selection on this button will show up after you start typing.

This has nothing to do with focus not being in editor body.

[Jakub Ś]

I have checked this issue one more time - it seems that if content area is empty there is no problem (can be checked in AJAX sample) but it occurs only if there is initial text (doesn't matter if text is plain, inside paragraph or div).

[Wiktor Walc]

Using IE and the plain contenteditable element, pressing keyboard shortcuts at the beginning of the paragraph:

Ctrl + B, Ctrl + U and Ctrl + I

works as expected and results in correct formatting:

<strong><em><u>text</u></em></strong>

In CKEditor the result is different (only the last style is applied, as reported in TC):

<em>text</em>

You can compare the results in CKEditor and contenteditable element using the attached replacebyclass sample.

I'm adding this comment, because I initially thought that IE is unable to apply more than one style.

[Frederico Caldeira Knabben]

Replying to wwalc:

Unfortunately your test page is wrong, when it comes to the problem we're facing.

The point is that the default behavior of, for example, CTRL+B is NOT the one users expect. If the editor is configured to produce <b> for bold, it'll keep producing <strong>.

Other than that, the problem is not exclusive to bold, italic and underline, the styles that IE provide default shortcuts. It impacts all inline styles, like strike-through, font name or size or the styles combo.

This is definitely an issue/limitation in the IE selection system. We have already lots of hacks for it in our code, but it looks like we still need further hacks to workaround this case.

I'm investigating this.

[Frederico Caldeira Knabben]

After a long investigation, I've figured out that the problem is in fact in IE... the sad part is that we'll hardly have ways to workaround it.

The problem is that, if the selection is inside an empty inline element at the START of a paragraph, document.selection.createRange() returns a range that is OUTSIDE the inline element.

If the element is at the middle or at the end of the paragraph, the range will be inside that element, as expected.

So the problem doesn't lie on our selection making code, but on the selection retrieval part of it: CKEDITOR.dom.selection::getRanges.

The nice thing is that IE9 introduced support for modern range/selection stuff, compatible with other browsers. After a quick test, I've confirmed that if we use the current-non-IE code for getRanges, it'll solve the problem. So there is a chance for IE9+.

But for IE8-, I think we'll hardly be able to find a solution and our poor XP users will have to leave with this.

I tried working on a reduced TC for this, to report it to MS, but I doubt they'll be interested on it, considering that this issue can be solved for IE9+. The other point is that it is pretty hard to come with this TC, because it is tricky to have the selection inside an empty element by code.

[Jakub Ś]

Possible duplicate #6140.

[Jakub Ś]

This is of course also reproducible in V4 as well (since this is IE issue)

[Piotrek Koszuliński]

We cannot reproduce this any more. We were able to confirm that it was reproducible on 3.6.x, but it isn't reproducible from around 4.0 beta.