Opened 13 years ago

Closed 9 years ago

#6706 closed Bug (fixed)

IE Selected format not applied to typed text

Reported by: Satya Minnekanti Owned by:
Priority: Normal Milestone:
Component: Core : Styles Version: 3.0
Keywords: IBM IE VendorFix Cc: Damian, joek, james, c

Description (last modified by Wiktor Walc)

To reproduce the defect

  1. Open any sample except AJAX.
  1. 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.

  1. See that only last selected icon(Strike Through) shown as selected in the Tool bar.
  1. 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

Attachments (3)

6706.patch (3.8 KB) - added by Garry Yao 13 years ago.
6707_2.patch (4.7 KB) - added by Garry Yao 13 years ago.
replacebyclass.html (2.9 KB) - added by Wiktor Walc 12 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 13 years ago by Garry Yao

Component: GeneralCore : Styles
Priority: NormalLow
Status: newconfirmed
Version: 3.4.23.0

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

Changed 13 years ago by Garry Yao

Attachment: 6706.patch added

comment:2 Changed 13 years ago by Garry Yao

Cc: james c added; James removed
Owner: set to Garry Yao
Status: confirmedreview

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

comment:3 Changed 13 years ago by Garry Yao

Keywords: IE added
Priority: LowNormal

comment:4 Changed 13 years ago by Sa'ar Zac Elias

Status: reviewreview_failed

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

comment:5 Changed 13 years ago by 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.

Changed 13 years ago by Garry Yao

Attachment: 6707_2.patch added

comment:6 Changed 13 years ago by Garry Yao

Status: review_failedreview

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.

comment:7 in reply to:  6 ; Changed 13 years ago by Frederico Caldeira Knabben

Status: reviewassigned

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.

comment:8 in reply to:  7 ; Changed 13 years ago by 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?

comment:9 Changed 13 years ago by Garry Yao

Keywords: VendorFix added
Owner: Garry Yao deleted
Status: assignedconfirmed

comment:10 in reply to:  9 Changed 13 years ago by Satya Minnekanti

Replying to garry.yao:

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

comment:11 in reply to:  8 Changed 13 years ago by 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.

comment:12 Changed 12 years ago by 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.

Last edited 12 years ago by Jakub Ś (previous) (diff)

comment:13 Changed 12 years ago by 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).

comment:14 Changed 12 years ago by Wiktor Walc

Description: modified (diff)

Changed 12 years ago by Wiktor Walc

Attachment: replacebyclass.html added

comment:15 Changed 12 years ago by Wiktor Walc

Description: modified (diff)

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.

comment:16 Changed 12 years ago by Wiktor Walc

Description: modified (diff)

comment:17 in reply to:  15 Changed 12 years ago by 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.

comment:18 Changed 12 years ago by 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.

comment:19 Changed 12 years ago by Jakub Ś

Possible duplicate #6140.

comment:20 Changed 11 years ago by Jakub Ś

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

comment:21 Changed 9 years ago by Piotrek Koszuliński

Resolution: fixed
Status: confirmedclosed

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.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy