Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12192 closed Bug (wontfix)

Caret disappears in Firefox

Reported by: Boris Lykah Owned by: Piotr Jasiun
Priority: Normal Milestone:
Component: General Version:
Keywords: Firefox Support vendorfix Cc:

Description

After executing action inside of a command, the caret disappears from the editor. If the same action is executed independently of CKEditor, the caret stays there.

For reproduction try the button "download file" (works) and the first button on the toolbar without an icon (caret disappears).

Attachments (7)

bug.html (1.9 KB) - added by Boris Lykah 4 years ago.
Reproduction
bug_smaller.html (1.6 KB) - added by Boris Lykah 4 years ago.
12192-bug_smaller-fixed.html (1.7 KB) - added by Piotr Jasiun 4 years ago.
12192-bug-fixed.html (2.0 KB) - added by Piotr Jasiun 4 years ago.
workaround_fails.html (2.8 KB) - added by Boris Lykah 4 years ago.
12192-workaround_fails_without_editor.html (876 bytes) - added by Piotr Jasiun 4 years ago.
12192-workaround_fails_without_editor.2.html (283 bytes) - added by Piotr Jasiun 4 years ago.

Download all attachments as: .zip

Change History (27)

Changed 4 years ago by Boris Lykah

Attachment: bug.html added

Reproduction

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

Keywords: Firefox added
Status: newconfirmed

I think that this is a bug in Firefox. I've seen it few times already in various scenarios (e.g. drag and drop, maximize), but I never could simplify the test case, so I haven't reported it finally. And there was always some workaround (e.g. changing order of doing things).

You can try reporting it this way or maybe you'll be lucky to limit the case so it does not involve CKEditor.

comment:2 Changed 4 years ago by Boris Lykah

I could not reproduce the bug without CKEditor. For me it also looks like a bug in Firefox but it seems that CKEditor also does something buggy since executing the action not as a command works.

CKEditor already does a great job in mitigating cross-browser issues, and even if it is not involved, it would be nice to have a fix or workaround for this bug too. I could not find a workaround and this bug is close to a showstopper for using our web app in FF.

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

I could not reproduce the bug without CKEditor. For me it also looks like a bug in Firefox but it seems that CKEditor also does something buggy since executing the action not as a command works.

That's exactly the problem I think - something CKEditor does triggers this bug in Firefox. So you remove CKEditor, there's no trigger, everything works just fine. This is a fragile issue - I remember adding timeout in some place and it was gone :).

I don't know if it's fix for the same problem, but check this: https://github.com/ckeditor/ckeditor-dev/blob/faebadca2c009096adc7190e3d6b584aabe0a03b/plugins/maximize/plugin.js#L71-L86

And also this: https://github.com/ckeditor/ckeditor-dev/blob/285231656e2e4624225168cbf9cb9d0870072a3e/plugins/clipboard/plugin.js#L1349-L1354

Maybe these hacks will give you some ideas.

Changed 4 years ago by Boris Lykah

Attachment: bug_smaller.html added

comment:4 Changed 4 years ago by Boris Lykah

Those hacks don't help. I have attached a smaller file without FileSaver dependency.

comment:5 Changed 4 years ago by Boris Lykah

After the caret is gone, a user cannot restore the caret and the application becomes completely unusable. So this issue has a high priority for us. One workaround is to implement a custom toolbar instead of CKEditor one, but that would require rewriting a lot of code.

comment:6 Changed 4 years ago by Piotr Jasiun

Status: confirmedpending

Cursor disappears if the editor has focus when the download dialog is shown. This is the reason why "download file" button works and toolbar button does not. The simplest workaround is to blur the editor right before the dialog is shown:

function downloadFile() {
    document.getElementById( 'editor1' ).blur();
    document.location = 'data:Application/octet-stream,0';
}

Alternatively you can fix missing cursor after dialog is closed using:

editor.editable().setAttribute( 'contentEditable', false );
editor.editable().setAttribute( 'contentEditable', true );

But you need to do it when the dialog is closed, not earlier.

Does this solution work for you?

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

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

I confirm that the workaround in 12192-bug_smaller-fixed.html​ works.

Changed 4 years ago by Piotr Jasiun

Changed 4 years ago by Piotr Jasiun

Attachment: 12192-bug-fixed.html added

comment:8 Changed 4 years ago by Piotr Jasiun

I've added both samples fixed.

comment:9 Changed 4 years ago by Boris Lykah

The blur workaround works for me. Thanks a lot!

comment:10 Changed 4 years ago by Piotr Jasiun

Resolution: fixed
Status: pendingclosed

Good to read this.

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

Resolution: fixed
Status: closedreopened

The issue has not been fixed. We know the workaround, but FF is still buggy.

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

Status: reopenedconfirmed

Changed 4 years ago by Boris Lykah

Attachment: workaround_fails.html added

comment:13 Changed 4 years ago by Boris Lykah

The workaround fails if we click on a menu item. Open workaround_fails.html, click download, choose Content from the menu. The content is updated and the caret disappears.

comment:14 Changed 4 years ago by Wiktor Walc

Keywords: Support added

comment:15 Changed 4 years ago by Piotr Jasiun

Owner: set to Piotr Jasiun
Status: confirmedassigned

Changed 4 years ago by Piotr Jasiun

comment:16 Changed 4 years ago by Piotr Jasiun

I simplified the sample and was able to reproduce it without the CKEditor.

  1. Open attached 12192-workaround_fails_without_editor.html​
  2. Click on the "download file" button.
  3. Click on the iframe next to the button.
  4. Click on the content editable.

And you have no cursor.

CKEditor use iframe to show dropdown in the toolbar, what seems to be a problem for Firefox. Note that everything is fine if you put the replaceContent directly in the toolbar instead of the dropdown (then iframe is not used).

I will report this issue to the Firefox team.

Changed 4 years ago by Piotr Jasiun

comment:17 Changed 4 years ago by Piotr Jasiun

I have attached even simpler version, without any JavaScript.

comment:18 Changed 4 years ago by Piotr Jasiun

Keywords: vendorfix added
Resolution: wontfix
Status: assignedclosed

I have reported this issue on the Firefox Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1146881

comment:19 Changed 4 years ago by Boris Lykah

Do you think there is a workaround for it?

comment:20 Changed 4 years ago by Piotr Jasiun

I tried multiple workarounds we used in similar cases. I tried to blur and focus editor, tried to focus parent windows when the button in the iframe is clicked, tied to use timeout and focus editor with the small delay, tried to disable and re-enable editor (set contenteditable=false and contenteditable=true) and none of these bring me a stable solution. The problem is even worst because the focus event was unstable when the cursor disappear.

Most probably there is some kind of workaround, but it would be an ugly hack and even less stable then the previous one. Apparently this is an instability inside Firefox engine so it means that any solution may be unstable too, because it is supposed to deal with unstable problem.

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