is this X11 or wayland ?

I tested with both, no change on either. Note I was using a VM to test but I think my user who made that video was not virtual.

I have not been able to reproduce with testnotebookdnd, which has some cases where it does set a pixbuf icon for a drag that tears a tab off.

Can you produce a testcase, or show your code ?

Here's the code I was using for the DragBegin and DragFailed before switching to using a Window instead. It's D code but hopefully it should be relatively easy to follow:

void onTitleDragBegin(DragContext dc, Widget widget) {
        trace("Title Drag begin");
        Pixbuf pb = getWidgetImage(this, 0.20);
        DragAndDrop.dragSetIconPixbuf(dc, pb, 0, 0);
    }

    /**
     * Called when drag failed, used this to detach a terminal into a new window
     */
    bool onTitleDragFailed(DragContext dc, GtkDragResult dr, Widget widget) {
        trace("Drag Failed with ", dr);
        if (dr == GtkDragResult.NO_TARGET) {
            //Only allow detach if whole heirarchy agrees (application, window, session)
            if (!notifyIsActionAllowed(ActionType.DETACH))
                return false;
            trace("Detaching terminal");
            Screen screen;
            int x, y;
            dc.getDevice().getPosition(screen, x, y);
            //Detach here
            Terminal terminal = getDragTerminal(dc);
            if (terminal !is null) {
                trace("Detaching terminal ", dr);
                notifyTerminalRequestDetach(terminal, x, y);
                terminalState = TerminalState.NORMAL;
                updateActions();
            } else {
                error("Failed to get terminal therefore detach request failed");
            }
            return true;
        }
        return false;
    }

Note you only get the leftover image if the DragFailed returns true, on false you get the normal failed animation and no leftover image.

The easiest way I can give you a reproducer is to build an older version of my application with the issue. If you need a small self-container reproducer, I can build one in D but it will take me a few days to get to it.

I dunno. Adding a few printfs to the GtkNotebook drag_Failed function, I see it take the same path and return TRUE, yet the icon gets cleared up just fine.

I just re-tested an older version of my application before I switched to Window on Rawhide just confirm the issue and still see it. You can try my app if you want, but it's a bit of a pain to setup manually because I don't have an archive of old RPMs.

1. Download terminix here: https://github.com/gnunn1/terminix/releases/download/0.52.1/terminix.zip

2. sudo unzip terminix.zip -d /

3. sudo glib-compile-schemas /usr/share/glib-2.0/schemas/

4. Run the app (terminix) and split the terminal into two using the menubutton over the terminal. Drag one of the terminals to the desktop and let go. It should detach the terminal and the pixbuf image will be left behind

Note I can completely understand not wanting to download some app off the internet and install it in your root file system just to reproduce this issue if you don't have a virtualized environment handy. I can work on a smaller, more self-container reproducer but can't get to it until the weekend at the earliest.

briefly looked at terminal.d, but didn't see anything obviously wrong. The only way I see for the icon to stick around is if we (or you) managed to leak a reference to the drag context somehow - we remove the drag icon/window in finalize(). So if the context doesn't get finalized, it might stick around

Did you look at the current code or the 52.1 tag, keep in mind that the current code in github works fine because I switched to a Window. I also had the thought it could be due to D's GC missing a reference or not destroying the Pixbuf promptly enough as I've had that problem with other cases. I did try adding a DragEnd handler that destroyed my reference to the Pixbuf that I passed and it didn't make any difference. Also, this same code worked fine in 3.18 so from my perspective the only change was to 3.19.

I set the severity to minor because I was able to workaround it by switching my implementation so I'm not looking for an urgent solution to this, just wanted to capture it in case others have the same problem. 

If you need a small reproducer let me know and I'm happy to spend an hour to build one during the weekend, though it will be in D.

(In reply to Gerald Nunn from comment #8)
> Did you look at the current code or the 52.1 tag, keep in mind that the
> current code in github works fine because I switched to a Window. I also had
> the thought it could be due to D's GC missing a reference or not destroying
> the Pixbuf promptly enough as I've had that problem with other cases. I did
> try adding a DragEnd handler that destroyed my reference to the Pixbuf that
> I passed and it didn't make any difference. Also, this same code worked fine
> in 3.18 so from my perspective the only change was to 3.19.

The problem is not the pixbuf, GDK creates a window internally to display it, and that window is destroyed when the drag context is finalized. It could well be that what you are seeing is the drag context being kept alive until gc kicks in. 

Is there a way to trigger gc explicitly in D ? that might be a way to test that theory.

There is a way, however it would have to be triggered outside the drag method since while in the method the reference to the D DragContext wrapping class is still valid. I'll pull my old code tonite and add an action to trigger it to see if it makes any difference and post the result.

Created attachment 324140 [details] [review]
dnd: Hide the drag window when we're done

We were just relying on the drag context finalize() to destroy
the window. But with garbage-collected bindings, that might
not happen as soon as we like, so explicitly hide the window
when the drag ends successfully.

Review of attachment 324140 [details] [review]:

Looks good, FWIW it seems that you can just hide the window always in wayland, as far as I've seen we just keep the last buffer around in the mutter side.

I'll leave a-c-n or a-c-afterfreeze to your discretion.

So I tested out calling GC.collect and it does indeed cause the drag image to disappear, interesting this was only ever in issue in GTK 3.19 and not previous versions.

(In reply to Gerald Nunn from comment #13)
> So I tested out calling GC.collect and it does indeed cause the drag image
> to disappear, interesting this was only ever in issue in GTK 3.19 and not
> previous versions.

Thats because DND support was rearchitected this cycle, moving much of the implementation down into GDK.

Review of attachment 324140 [details] [review]:

going to hold this until after the release.

Attachment 324140 [details] pushed as 068d382 - dnd: Hide the drag window when we're done