Regression: Doesn't work in Firefox. about elm-html5-drag-drop

[ymtszw]

Let me drop a comment on the workaround.

Setting DataTransfer via port indeed works, and if you are OK with it, you can go for it.
As for the old workaround mentioned by @ABinaryGeek , though it won't work when dragstart isn't bubbling up, actually you can do the same thing on capturing phase, which should work regardless of stopPropagation:

document.addEventListener("dragstart", function(event) {
  event.dataTransfer.setData("text/plain", "");
}, true);

(change 3rd parameter to true)

For some reason you are hesitent to introduce port, this may help. As always, be careful of possible side-effects. 😜
Ref: Order of event handler application
Ref2: Param of addEventListener()

[ABinaryGeek]

A simple workaround, external JS but no ports needed:

You can set up a global event listener for the document, and do it there. Obviously this could be an issue if you had other non-elm-managed drag-drop stuff going on, but for simple cases it seems to do the job.

document.addEventListener("dragstart", function(event) {
    event.dataTransfer.setData("text/plain", "");
}, false);

[norpan]

Yes, however, I did try it and it worka in the latest firefox. Thanks for that simple fix, I’ll add it to the docs. mån 8 okt. 2018 kl. 00:29 skrev ABinaryGeek <[email protected]>:

…

A simple workaround, external JS but no ports needed: You can set up a global event listener for the document, and do it there. Obviously this could be an issue if you had other non-elm-managed drag-drop stuff going on, but for simple cases it seems to do the job. document.addEventListener("dragstart", function(event) { event.dataTransfer.setData("text/plain", ""); }, false); — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABmnyuvrvn5jhqXnejtiLgyo8fT0VSLpks5uioA6gaJpZM4XMDu3> .

[panthus]

As of version 3.0.2 the workaround mentioned here is no longer possible due to the disabled event propagation. A port workaround is also not possible because the dragstart event args are not exposed.

Is it possible to allow one of these options?

[norpan]

I'm not sure what you mean, there has been no change in how the dragstart event is handled. It should still propagate. Could you provide more info?

[panthus]

I mean line 218 in this commit: f85518c

It disables event propagation for dragstart.

[norpan]

Oh, I see. Yes, that seems to be an unfortunate side effect. I guess the easiest way is to stick with the previous version for now. I don't think propagating the dragstart event is a good thing because it means you can't have nested draggables. Perhaps there is a better way to fix Firefox. As I said before it works for me in the latest Firefox so it may be fixed there.

Another options is to change the API to allow people to propagate the event or not, but the use case for propagating is still weak, so it'll take a better use case than to fix a broken obsolete version of a browser to add it.

[panthus]

The issue still occurs on the latest Firefox on Windows. I just verified that it works on Linux though.

The open bug report can be found here: https://bugzilla.mozilla.org/show_bug.cgi?id=1352852.

I agree with your reason for not enabling propagation. What about exposing the dragstart event args as a Json.Decode.Value? It would allow the use of ports to change effectAllowed and setDragImage, besides using setData to fix Firefox on Windows.

Edit: Apparently it also does not work on Linux, but if you drag an img then it works everywhere. If you try to drag a div then it does not.

[z5h]

Here's an Ellie with drag & drop that works in Safari & Chrome but fails in Firefox (on OSX at least).

https://ellie-app.com/3V4gkmgBD5Ba1

[norpan]

I made a new version which has the getDragstartEvent function that seems to work. See the example folder.

[harrysarson]

I can confirm that @z5h's ellie does not work on Firefox on windows either.

[panthus]

Thanks @norpan, that fixes the problem!

With one side-note though, although that looks like a bug in the elm debugger. It does not always work if you compile the code with the debugger enabled. For some reason it executes the port async if the debugger is enabled (as evident in the stack trace). If the debugger is disabled then the port is executed sync and it works. According to the spec it should always be sync in this case: https://package.elm-lang.org/packages/elm/virtual-dom/latest/VirtualDom#Handler.

In debug mode I get the following error, which means that the event.dataTransfer object has become read-only: NoModificationAllowedError: Modifications are not allowed for this document. The event.dataTransfer object becomes read-only after the drag start event has occurred in Firefox. If the port is async then the drag start event is already completely handled so that makes sense.

Your example does not seem to suffer this behavior though, so it has something to do with the more complex SPA setup that I have. I can't seem to reproduce it in a small example...

[norpan]

Great! I'm closing this, with the fix in eae919d.

Regarding the debugger error, if you can produce an example, please file it against the elm compiler, with a reference to this issue.

[norpan]

That's great @ymtszw! I'll add it to the docs as the easiest workaround.

[rwoodnz]

I have same problem with the workaround not working in debug mode.
#9 (comment)
@panthus thanks for the explanation on this. Did you come up with a way to resolve it or did you just live with it?

[panthus]

@rwoodnz I have not found a solution for the issue with debug mode. I’m currently unable to use debug mode because of elm/compiler@af2ea2b so it hasn’t been on my list.