Caret disappears in Firefox

[Boris Lykah]

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).

[Boris Lykah]

Reproduction

[Piotrek Koszuliński]

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.

[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.

[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.

[Boris Lykah]

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

[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.

[Piotr Jasiun]

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?

[Piotrek Koszuliński]

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

[Piotr Jasiun]

I've added both samples fixed.

[Boris Lykah]

The blur workaround works for me. Thanks a lot!

[Piotr Jasiun]

Good to read this.

[Piotrek Koszuliński]

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

[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.

[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.

[Piotr Jasiun]

I have attached even simpler version, without any JavaScript.

[Piotr Jasiun]

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

[Boris Lykah]

Do you think there is a workaround for it?

[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.