Cursor invisible after drag-n-drop in Firefox

[0b10011]

1. Load http://prosemirror.net/
2. Drag logo into the ProseMirror editor example
3. Click somewhere in the editor
4. Type "foo"

Expected: Cursor should appear after step 3, and "foo" should be inserted

Actual: Cursor never appears, but "foo" is still inserted at the proper location

Appears to be a bug with Firefox's contenteditable implementation (there are several on bugzilla regarding the cursor). I haven't dug into it too much yet, but clicking elsewhere (eg, the "A toolkit..." title) and then clicking back into the editor will show the cursor again.

[marijnh]

There's not a whole lot we can do about browsers being terrible, especially when its effect isn't actually observable in JavaScript. If you want to help, investigating whether other contentEditable-based editors are affected and seeing if they have a working workaround would be a good approach.

[0b10011]

Yeah, I meant to mention I was going to look into this later. (There's a good chance I'll be opening several issues over the next week or so... I'm going to try to follow up on them myself if you aren't able to get to them.)

The workaround mentioned in the linked stackoverflow thread mentions focusing a generated <a> and then setting the focus back to the [contenteditable] element. I'll try playing around with this next week sometime. (I'll also be opening a bug on bugzilla if I can't find an existing one for the exact issue.)

[adrianheine]

I have a similar issue in Firefox I think due to having stored marks and thus a cursor wrapper.

[marijnh]

Can this be reproduced in a demo? Does force-resetting the DOM selection after drop help?

[adrianheine]

@0b10011 gave steps for prosemirror.net, but I cannot reproduce the issue with those steps in my FF56. As for my incarnation of the issue: It is reproducible with a rather simple modification to the basic demo. You need to have a background-color and a stored mark. It's probably what this person on Stackoverflow ran into.

[marijnh]

Okay, so then drag-and-drop isn't actually involved. Opening a new issue #712

[frederik]

Here is a glitch that reproduces the issue after a drag.

(mostly unmodified Dinosaur demo).

As indicated, these seem to be separate issues. This one might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=800050 though I did not get the workaround mentioned in the last post to work.

[afwn90cj93201nixr2e1re]

https://sticky-ferret.glitch.me Lil typo fixes.

[jljorgenson18]

You can resolve this by having a hidden input somewhere and then after you are done handling the drop event, you move the native selection into that hidden input and then move it back to inside of PM. It forces a sort of soft reset where Firefox will fix itself. You can use a selection bookmark to restore the selection and you will need to all restore storedMarks and then call view.focus. If you do that though, the cursor should come back.

We use this "cursor parking" technique in a few spots to get around weird native issues where the browser breaks something on prevented events or the browser ignores your prevent defaults (like the touchbar with Safari).

[jljorgenson18]

Just to note, you do need a set timeout between moving the focus and restoring the selection.

[jljorgenson18]

Posted in the discussion forum with an example https://discuss.prosemirror.net/t/cursor-parking-a-tool-to-help-handle-native-browser-issues/2107

[marijnh]

Does this still happen for anyone with current Firefox versions?

[aduchate]

I still have a similar problem on Firefox 84, when I use web components. When I have 2 prosemirror instances on the same page, each in their own shadow dom. If I try to switch from one PM to the other without clicking first on the background of the window, the carret is not displayed, though the focus is set correctly and typing works as expected.

Update: I created a separate issue : https://github.com/ProseMirror/prosemirror/issues/1113 for this