Opened 5 years ago

Closed 5 years ago

#10787 closed Bug (fixed)

Divarea and inline breaks replacement of text selection in Firefox

Reported by: Alexander Ebert Owned by: Olek Nowodziński
Priority: Must have (possibly next milestone) Milestone: CKEditor 4.3.2
Component: General Version: 4.0
Keywords: Firefox Cc:

Description

Using Firefox, one is not always able to replace selected text by pasting contents from clipboard. I have successfully identified this issue raised by the divarea plugin, disabling it fixes the issue.

You can reproduce this using the online demo:

  1. Open http://ckeditor.com/demo#div in Firefox
  2. Copy a short string (e.g. "example") into your clipboard
  3. Double-click on the term "spaceflight" in the first line of the very first paragraph
  4. Insert clipboard contents by using CTRL+V or Right-Click -> Paste

The selected text was not replaced, instead the clipboard contents gets inserted right in front of the original selection:

Expected result: "Apollo 11 was the example that landed the first humans, [...]"

Actual result: "Apollo 11 was the examplespaceflight that landed the first humans, [...]"

This problem persists unless a text block is splitted into own text nodes. Simply mark the term "spaceflight" again and you can now replace it by pasting contents.

I was able to confirm this issue with both CKEditor 4.1.1 and the online demo using Firefox 23.0.1, other browsers seem to be not affected.

Change History (13)

comment:1 Changed 5 years ago by Alexander Ebert

Summary: divare breaks replacement of text selection in Firefoxdivarea breaks replacement of text selection in Firefox

comment:2 Changed 5 years ago by Alexander Ebert

This is not limited to the divarea-Plugin, the "Inline editing"-mode suffers from the same issue, the above steps can be reproduced on http://ckeditor.com/demo#inline too.

comment:3 Changed 5 years ago by Jakub Ś

Keywords: Firefox added
Status: newconfirmed
Summary: divarea breaks replacement of text selection in Firefoxdivarea and inline breaks replacement of text selection in Firefox
Version: 4.0

I was able to reproduce this issue with inline and divarea samples in Firefox only from CKEditor 4.0 (doesn't occur in CKE 4 beta).

comment:4 Changed 5 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 4.3.2

comment:5 Changed 5 years ago by Olek Nowodziński

Priority: NormalHigh

comment:6 Changed 5 years ago by Olek Nowodziński

Owner: set to Olek Nowodziński
Status: confirmedassigned

comment:7 Changed 5 years ago by Olek Nowodziński

There's a branch t/10787 (+tests) that contains a very dirty fix which is quite likely bad but reveals the problem.

It turns out that FF might prefer pastebin located in editable to <html> or <body>, just like Webkit.

Another funny fact is that once pasting fails, repeating 2-4 is successful in most of subsequent attempts. It might indicate some timing problem.


A different approach that also seems to solve the problem:

--- a/plugins/clipboard/plugin.js
+++ b/plugins/clipboard/plugin.js
@@ -762 +762 @@
-                       if ( CKEDITOR.env.webkit )
+                       if ( CKEDITOR.env.webkit || CKEDITOR.env.gecko )
Last edited 5 years ago by Olek Nowodziński (previous) (diff)

comment:8 Changed 5 years ago by Alexander Ebert

From what I have observed, splitting the next node right in front of it, directly afterwards or within the target word will make it work on the first attempt.

Just observe what happens if you do perform the steps above, it splits the next node and the inserted text is at the end of the first text node, while the term spaceflight is at the very beginning of the next text node.

I'm not quite sure if there's a correlation between this and the actual behavior, but it at least explains under which circumstances the replacement works, even though it doesn't explain why it works at all. Chances are this is not related to an timing issue, but I may be wrong.

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

First of all, we should not guess.

During debugging I noticed that bookmarks created before inserting pastebin are not correctly restored. Or rather - that something weird happens to selection, because it returns range at the beginning of the paragraph (I was checking right after selectBookmarks() call). This may be caused by some bug in code handling selection#selectRanges when selection is locked (because it is locked at that moment). But I also think that selection should not be locked any more when bookmarks are restored. I see that there's special code for IE which restores focus, but it causes editor blur when used on FF. It also doesn't make sense to focus editable, because it apparently has focus. So it may be a different kind of problem which I know from widgets. Firefox may fire blur on editable without firing focus then. In this case it would make sense to use the same hack as on webkit - blocking blur event.

So, summarising:

  1. there may be a bug in selectRanges done when selection is locked - it should be checked, but it does not seem to be a root of this issue,
  2. reasonable and justifiable fix would be what you proposed as "A different approach" - so cancelling blur.

comment:10 Changed 5 years ago by Olek Nowodziński

Status: assignedreview

To not to waste time, I pushed a solution adapted from #10644 to t/10787b (tests in t/10787).

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

Summary: divarea and inline breaks replacement of text selection in FirefoxDivarea and inline breaks replacement of text selection in Firefox

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

Status: reviewreview_passed

While reviewing this ticket I found a bug on IEs (#11384) and I had to add this ticket's test to ignored ones for IEs. Besides that - patch works for FF.

comment:13 Changed 5 years ago by Olek Nowodziński

Resolution: fixed
Status: review_passedclosed

git:2e6d50b landed in master (6280974 tests).

Note: See TracTickets for help on using tickets.
© 2003 – 2017 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy