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).