Opened 14 years ago

Closed 14 years ago

#4734 closed Bug (fixed)

[IE8] Font size resets when font name is changed in an empty numbered list.

Reported by: Joe Kavanagh Owned by: Garry Yao
Priority: Normal Milestone: CKEditor 3.3
Component: Core : Lists Version:
Keywords: Confirmed IE8 IBM Review+ Cc: dchojna@…, satya_minnekanti@…

Description (last modified by Frederico Caldeira Knabben)

Use IE8 with compatibility mode off.

  1. Open the Ajax sample and click the "Create Editor" button.
  2. Tab into the editor content area.
  3. Click the Numbered List button to start a list (leave it empty).
  4. Select a font size.
  5. Select a font family.

Observe that the font size field resets to "Size"

Attachments (2)

4734.patch (1.7 KB) - added by Garry Yao 14 years ago.
4734_2.patch (1.2 KB) - added by Garry Yao 14 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 14 years ago by Frederico Caldeira Knabben

Keywords: Confirmed IE8 added

Confirmed with IE8 No-Compat only. Works well with IE8 Compat and FF.

comment:2 Changed 14 years ago by Garry Yao

Culprit is unable to put cursor into an inline element at the start of a list item.

comment:3 Changed 14 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 3.2

comment:4 Changed 14 years ago by Damian

Reproduced in Safari 4.0.4 on Win XP.

comment:5 Changed 14 years ago by Garry Yao

Milestone: CKEditor 3.2CKEditor 3.3

It's really a reduced bug copy of #1272 on IE (where it only fails when selection's in front of a list), similar with that one, we could hardly have any fix for it at the moment.

comment:6 Changed 14 years ago by Damian

In #1272, we are waiting on a fix from Webkit. Are we expecting a fix from IE in this case? If so, we need a defect raised.

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

Description: modified (diff)

Replying to damo:

In #1272, we are waiting on a fix from Webkit. Are we expecting a fix from IE in this case? If so, we need a defect raised.

No, for now we need more investigation on this. I'm not sure it has anything to do with #1272 as IE has a completely different selection system.

comment:8 Changed 14 years ago by Garry Yao

Yet another problem caused by the new doctype of document, we're free of bug in v2.

Changed 14 years ago by Garry Yao

Attachment: 4734.patch added

comment:9 Changed 14 years ago by Garry Yao

Keywords: Review? added
Owner: set to Garry Yao
Status: newassigned

Proposing of using selection lock to work around this issue.

comment:10 Changed 14 years ago by Satya Minnekanti

Cc: satya_minnekanti@… added

comment:11 Changed 14 years ago by Frederico Caldeira Knabben

Keywords: Review- added; Review? removed

After the patch, with IE8, the panels started to get quite unstable, sometimes not opening on click. It's easy to check it with the following tc:

  1. Open a sample.
  2. Put the selection in the editing area.
  3. Click the Format combo.
  4. With that combo opened, click any of the color buttons. It will show and hide immediately.

Another problem happens with selection changes when the combo is opened. You must first click the editor (to close the combo) and then make the selection. It's not possible to do it with the combo opened in a single move.

Changed 14 years ago by Garry Yao

Attachment: 4734_2.patch added

comment:12 Changed 14 years ago by Garry Yao

Keywords: Review? added; Review- removed

You must first click the editor (to close the combo) and then make the selection. It's not possible to do it with the combo opened in a single move.

This's really the limitation of the previous approach and simply can't get a workaround, providing yet another way for the bug.

comment:13 Changed 14 years ago by Frederico Caldeira Knabben

Keywords: Review+ added; Review? removed

comment:14 Changed 14 years ago by Garry Yao

Resolution: fixed
Status: assignedclosed

Fixed with [5452].

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