Opened 12 years ago

Closed 12 years ago

#9699 closed Bug (fixed)

Applying font styles to selection in inline mode creates empty element instead

Reported by: Alex Lee Owned by: Piotrek Koszuliński
Priority: Normal Milestone: CKEditor 4.0.1
Component: Core : Selection Version: 4.0
Keywords: Cc:

Description

When using an inlined editor, attempting to change font styles (either typeface or font size) results in an empty span being appended to the end of selection instead of changing the selection.

Steps to reproduce:

  1. Create an inline instance on a contenteditable element
  2. Enter a paragraph of text
  3. Select the paragraph of text from the right end to the left, starting from an empty space
  4. Use font plugin's richcombos to change the font size

Note: it is important how the selection is made. Selecting by double/triple clicking or Ctrl-A will always work.


As far as I can tell, this is due to the font plugin's use of richcombos that change the browser focus. Doing the same selection but using simple styles like bold/italics/underline works 100% of the time.

Tracing through the selection plugin, I found that window.getSelection() reports the selection as isCollapsed. However, when selecting another way (like Ctrl-A) avoids that.

Change History (9)

comment:1 Changed 12 years ago by Piotrek Koszuliński

Milestone: CKEditor 4.0.1
Status: newconfirmed

Confirmed on Chrome. Perhaps similar issue to #9758.

comment:2 Changed 12 years ago by Piotrek Koszuliński

Owner: set to Piotrek Koszuliński
Status: confirmedassigned

comment:3 Changed 12 years ago by Piotrek Koszuliński

This issue is reproducible on FF and Webkits. git:4086b04 is a first bad commit. It's a part of fix for #9474. Changes were explained by Garry in git:10272e4.

comment:4 Changed 12 years ago by Piotrek Koszuliński

Before #9474 we've been locking selection retrieved on editable#blur. Since then we're not - we are updating variable which keeps last selection every time we execute checkSelectionChange. This check is triggered by multiple events - selectionchange, mouseup, keyup, focus. None of them is fired on editable when text is selected by dragging and mouse button is released outside editable.

Pushed prototype of a patch to git:d817327. Now we need to understand which browsers need it (Webkit&Gecko for sure) and if it is needed for framed editor (if only Webkit&Gecko need it, then it won't have any impact on framed editor, because these browsers don't need selection locking in that case).

comment:5 Changed 12 years ago by Piotrek Koszuliński

Results of test:

  1. focus editor,
  2. select by dragging and release mouse button outside editable,
  3. check cut/copy buttons - if enabled then selectionChange definitely was fired, apply font size.

Results

Webkits

  • Framed - no selectionChange, correct locked
  • Inline - no selectionChange, incorrect locked

IEs

  • OK

Opera

  • Framed - no selectionChange, incorrect locked
  • Inline - no selectionChange, correct locked

Firefox

  • Framed - no selectionChange, correct locked
  • Inline - no selectionChange, incorrect locked

No selectionChange fired in this case is a separate issue. Extracted to #9851.

Last edited 12 years ago by Piotrek Koszuliński (previous) (diff)

comment:6 Changed 12 years ago by Piotrek Koszuliński

Status: assignedreview

Pushed git:0428785 with patch targeted precisely for broken cases.

comment:7 Changed 12 years ago by Piotrek Koszuliński

Patch proposed in comment:6 fixes also #9758.

comment:8 Changed 12 years ago by Frederico Caldeira Knabben

Status: reviewreview_passed

It'll require a lot of monkey testing, but it looks good at a first glance.

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

Resolution: fixed
Status: review_passedclosed

Fixed with git:b1ec0a6.

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