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:
- Create an inline instance on a contenteditable element
- Enter a paragraph of text
- Select the paragraph of text from the right end to the left, starting from an empty space
- 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
Milestone: | → CKEditor 4.0.1 |
---|---|
Status: | new → confirmed |
comment:2 Changed 12 years ago by
Owner: | set to Piotrek Koszuliński |
---|---|
Status: | confirmed → assigned |
comment:3 Changed 12 years ago by
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
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
Results of test:
- focus editor,
- select by dragging and release mouse button outside editable,
- 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.
comment:6 Changed 12 years ago by
Status: | assigned → review |
---|
Pushed git:0428785 with patch targeted precisely for broken cases.
comment:8 Changed 12 years ago by
Status: | review → review_passed |
---|
It'll require a lot of monkey testing, but it looks good at a first glance.
comment:9 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | review_passed → closed |
Fixed with git:b1ec0a6.
Confirmed on Chrome. Perhaps similar issue to #9758.