Opened 11 years ago
Closed 11 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:
- Open http://ckeditor.com/demo#div in Firefox
- Copy a short string (e.g. "example") into your clipboard
- Double-click on the term "spaceflight" in the first line of the very first paragraph
- 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 11 years ago by
| Summary: | divare breaks replacement of text selection in Firefox → divarea breaks replacement of text selection in Firefox |
|---|
comment:2 Changed 11 years ago by
comment:3 Changed 11 years ago by
| Keywords: | Firefox added |
|---|---|
| Status: | new → confirmed |
| Summary: | divarea breaks replacement of text selection in Firefox → divarea 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 11 years ago by
| Milestone: | → CKEditor 4.3.2 |
|---|
comment:5 Changed 11 years ago by
| Priority: | Normal → High |
|---|
comment:6 Changed 11 years ago by
| Owner: | set to Olek Nowodziński |
|---|---|
| Status: | confirmed → assigned |
comment:7 Changed 11 years ago by
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 )
comment:8 Changed 11 years ago by
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 11 years ago by
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:
- 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,
- reasonable and justifiable fix would be what you proposed as "A different approach" - so cancelling blur.
comment:10 Changed 11 years ago by
| Status: | assigned → review |
|---|
comment:11 Changed 11 years ago by
| Summary: | divarea and inline breaks replacement of text selection in Firefox → Divarea and inline breaks replacement of text selection in Firefox |
|---|
comment:12 Changed 11 years ago by
| Status: | review → review_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 11 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | review_passed → closed |
git:2e6d50b landed in master (6280974 tests).
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.