I’m working on drag-and-drop functionality for my icon library plugin Phosphor Icons, and thanks to an excellent demo from jackiecorn on GitHub, it’s working beautifully. But there are a few pain points I was hoping the Figma developers could address:
In order to compute the canvas position of a dropped element, you have to do some hand-wavy math to figure out if the UI (sidebars and toolbars) are visible, and factor that in to your insertion coordinates. It would be super helpful if the API exposed a way to determine whether the UI was visible, and if so, what size they are. Or even better, a translation of plugin coordinate-space to canvas coordinate-space.
The canvas does not appear to accept drop events from drag initiated in a plugin window (drop is handled through the Figma API, but the cursor always appears as not-allowed). It would improve the discoverability for plugin users if it could appear as a copy or move cursor:
Thanks for all the work you all put into the Figma ecosystem.
I’m still getting the cancel icon when using the new sample code for testing the drop event type.
I have found that when developing something similar with just plain html and js, I can add the drop event listener to the location where I want to drop my items and that will remove the cancel icon.
Is there a way to add an event listener to the figma canvas/editor area?
My end goal is to be able to display the cancel icon while the item is being dragged in the plugin window, but show the drop icon when it is out of the canvas.
I want to second Ben_Smith’s request about event listeners in the editor.
It’s great to have the drop event in the API now, but on OSX (or rather with webkit specifically), dragging and dropping is not a great experience.
I gather this is because dragend is really the only event we can trigger the drop, since we are outside the plugin iframe. On Windows and Linux, this does not seem to be a problem, because dragend is called immediately when you drop an item outside the iframe. This is not the case on OSX. There’s a delay before dragend is called, as well as the “cancel” animation which pulls back the dragged item to origin.
If we wanted to solve this for web, it requires two steps:
preventDefault on dragover event
Make sure drop event is called
But in a figma plugin it becomes very tricky. We can’t preventDefault on dragover in the canvas since we are limited on the event listeners. Heck, even if I had access to a mouseup event, I could make it work.
It would be great if there was something you could do to make the experience of DND better on OSX, or even just expand the event listeners available in the API.
We just released a FigJam plugin that has drag-and-drop features and uses a non-null origin plugin iframe to initiate the drag operation.
We followed this reference plugin / guide to the T:
And it works great in the Figma desktop app, but strangely not in the browser (maybe just on macOS?)!
The figma.on(“drop”, …) event never fires for us in the browser Figma experience, despite working just fine in the desktop app.
Anyone else run into this quirk and have a workaround?
Relatedly: Really wish we could test dev plugins in the browser in addition to the desktop app to catch incompatibility gotchas like this before a plugin is released!
Does someone have some example on how to stop showing the native ‘not-allowed’ that appears as soon as we start dragging on the Figma canva? This happens just on Windows, exactly the same way that is shown in the initial question. Everything works just fine, but the ‘not-allowed’ icon is super misleading