Drag-drop item into Collections seems to have stopped working - SOLVED

edited 9 days ago
Hi all,

I enjoy all the new enhancements of Zotero and can't imagine how I would work without it.

One thing I especially find useful is the ability to "drag" an item from the (top) display pane into another Collection (I use the Stacked View). I have an Inbox Collection that I use when importing new references, processing them, and deciding where they will go. Once done, I then drag them to the Collection I think they belong in (ie drag from the display pane to the Collection name in the left Collections pane).

However, it seems that this functionality has vanished in the new version (7.0.21, 64 bit, Linux). I know I can just do a right-click and select Add to Collection, but I am wondering if this change was intended or if it is a bit of bug?

Thanks, as ever, for the great work!
  • Works for me. Are you sure the item you want to move does not already exist in the destination collection?
  • edited 9 days ago
    Ah, I see what is happening. It now takes a couple of seconds for the cursor to highlight the Collection into which the item is to be dragged. This is a longer delay than what I have been accustomed to (when it was pretty much instant). So, yes, it does work; just not as quickly as I had gotten used to ;-)

    Changing the Subj: line now...
  • Strange. It is instantaneous for me. Are you running any plugin that could impact the collection highlighting?
  • edited 9 days ago
    The only plugin I am running is the Better BibTeX plugin, without which most of my workflow would not flow at all.
  • edited 9 days ago
    Yes, there is a significant delay before the drag and drop operation of an item starts working, even without any plugin:
    https://forums.zotero.org/discussion/113721/zotero-7-beta-time-delay-when-doing-a-drag-and-drop-of-an-item
  • edited 9 days ago
    Interesting. This has only happened since I updated to the latest version a few days ago (or so). Strange that a behaviour from beta has resurfaced in the latest post-beta version.
  • Cannot reproduce on either in 7.1-beta.44 or 7.0.21 on Linux. Strange.
  • This has only happened since I updated to the latest version a few days ago (or so).
    I have always seen the problem on Windows since that post.

    The problem is due to the Quick Copy. Whenever you drag an item, it puts the Quick Copy in the clipboard. So the speed at which you can do a drag and drop depends on the Item Format setting in Quick Copy.
    I am using APA 7th edition, which is very slow I remember. If I switch to IEEE, the drag and drop is very fast.

    @jvoros: Have you changed your preferred Item Format in the Quick Copy settings recently? Which format are you using?
  • edited 9 days ago
    Yes, pretty sure that's right (though obviously not ideal)
    Have you changed your preferred Item Format in the Quick Copy settings recently? Which format are you using?
    It needn't have been an active change -- the Chicago styles have gotten much larger (and hence slower) recently and auto-update
  • edited 9 days ago
    Hmm. I am on 7.0.21 on Linux, using the .deb files provided by retorque.re.
  • I don't see why this would be Windows specific; see mjthoraval's explanation which I'd expect to apply on all systems (though the extent will vary with both style and computer speed)
  • I have experimented with it now. Changed from Chicago 18th to 17th to Vancouver to Turabian. There seems to be a delay on all of those formats.
  • I see, the Quick Copy is the culprit. Just tried with APA 7th and it is drastically slowing the process. Good to know
  • edited 9 days ago
    which I'd expect to apply on all systems
    I can reproduce the slow/fast drag and drop behaviour when switching from APA 7e to IEEE on an Ubuntu workstation with high specs. But it indeed gets worse for lower specs computers.

    @jvoros: Vancouver is fast for me.
    So it may be a different problem in your case.
    Can you show the full Export settings that you are using, and which linux distribution you are using?

    The devs may need to see a Debug ID (with all plugins disabled) for a slow drag and drop operation to investigate further.
  • I'd try Vancouver one more time before troubleshooting more; seems unlikely that this would be a different issue
  • edited 9 days ago
    Yes, Vancouver seems to be flying now - pretty much instant. Don't know why it seemed longer before. I am running Debian 12, using the deb files provided by retorque.re (ie not a flatpak or snap).
  • If you want to keep your preferred quick copy format, a workaround is to disable the Quick Copy when doing a drag and drop. You can still use the Quick Copy through the Ctrl/Cmd+Shift+C shortcut. I don't know if there are limitations compared to drag and drop.
    As a temporary workaround, if you don't need Quick Copy you could set "Disable Quick Copy when dragging more than [x] items" to 0.
    https://forums.zotero.org/discussion/comment/190770/#Comment_190770

    The relevant setting in the Config Editor (Settings → Advanced) is:
    extensions.zotero.export.quickCopy.dragLimit
  • Ah, that's terrific, hadn't occurred to me.
  • edited 9 days ago
    @mjthoraval Unfortunately, MarkDown doesn't seem to work here, nor do emoji, but :clap:
  • Are you talking about Note Templates MarkDown exports?
    https://www.zotero.org/support/note_templates
    https://forums.zotero.org/discussion/94663/available-for-beta-testing-note-templates-for-pdf-annotations/p1

    I see indeed that disabling the Quick Copy when doing a drag and drop breaks the Note Template when exporting to Obsidian by drag and drop:
    https://s3.amazonaws.com/zotero.org/images/forums/u265723/3a6zhra972mz7c0om18w.png

    But it still works fine when doing a drag and drop to a Zotero Note. So I think that this behaviour is not correct and it should still work for note exports (?).

    I realise that the option to disable Quick Copy is accessible in the Export settings directly instead of going to the Config Editor:
    https://s3.amazonaws.com/zotero.org/images/forums/u265723/d1hk0yolpqhwrztzs9bc.png
    But it is not clear if that setting should apply only to Items or also Notes.
  • I think this was just about the lack of markdown support on the forums. I'm still hoping we'll get this at some point. I've typed 'blockquote' a lot...
  • What I meant was: these Forums do not appear to support MarkDown so I couldn't easily do a :clap: emoji to applaud your fix. ;-)
  • I see. Thanks.
    This still answers my own question about the drawbacks of using that workaround.
    Hopefully that problem (and the original problem) can be addressed in Zotero.
  • edited 2 days ago
    The delay on drag should be fixed in the Zotero beta.
Sign In or Register to comment.