Opened 14 years ago
Last modified 10 years ago
#6706 closed Bug
IE Selected format not applied to typed text — at Version 15
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 )
To reproduce the defect
- Open any sample except AJAX.
- 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.
- See that only last selected icon(Strike Through) shown as selected in the Tool bar.
- 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 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
Change History (18)
comment:1 Changed 14 years ago by
Component: | General → Core : Styles |
---|---|
Priority: | Normal → Low |
Status: | new → confirmed |
Version: | 3.4.2 → 3.0 |
Changed 14 years ago by
Attachment: | 6706.patch added |
---|
comment:2 Changed 14 years ago by
Cc: | james c added; James removed |
---|---|
Owner: | set to Garry Yao |
Status: | confirmed → review |
It affects only collapsed cursor at the start of non-empty block.
comment:3 Changed 14 years ago by
Keywords: | IE added |
---|---|
Priority: | Low → Normal |
comment:4 Changed 14 years ago by
Status: | review → review_failed |
---|
Hit New Page, then Bold. JS error is thrown.
comment:5 Changed 14 years ago by
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 14 years ago by
Attachment: | 6707_2.patch added |
---|
comment:6 follow-up: 7 Changed 14 years ago by
Status: | review_failed → review |
---|
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 follow-up: 8 Changed 14 years ago by
Status: | review → assigned |
---|
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 follow-up: 11 Changed 13 years ago by
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 follow-up: 10 Changed 13 years ago by
Keywords: | VendorFix added |
---|---|
Owner: | Garry Yao deleted |
Status: | assigned → confirmed |
comment:10 Changed 13 years ago by
Replying to garry.yao:
@garry.yao could you please add the ticket that you logged with Micrrosaoft for this issue
comment:11 Changed 13 years ago by
Replying to damo:
Replying to fredck:
For now, I've opened an issue at Microsoft for this:
https://connect.microsoft.com/IE/feedback/details/671206I 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 13 years ago by
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.
comment:13 Changed 13 years ago by
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 13 years ago by
Description: | modified (diff) |
---|
Changed 13 years ago by
Attachment: | replacebyclass.html added |
---|
comment:15 Changed 13 years ago by
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.
Mark as low priority because of precondition "With out focus in Editor body".