This sounds more like it could address it, tbh.
I recreated it with traditional drag & drop and it works absolutely fine. It needs no timer and no ticking, so it’s really efficient to boot. It does create one super uncanny effect I’ve yet to see elsewhere, though. Will investigate if I ever find the time but it’s irrelevant here.
Your issue:
You’re nesting things unnecessarily deep and then shift elements inside itself. Don’t. Shift the entire backup widget inside the canvas of the main widget instead. Otherwise the anchor does not know what to do with the weirdly distorted local space / desired size.
Look up Drag & Drop tuts to see how they work. And how to reference the pop up is shown somewhere above.
Look up drag & drop tuts to see how the feature works.
If you do not want to use D&D, you could probably get away it with a timer (or tick) - the method you opted for originally but it’s somewhat crude. Not sure how non-sustainable and maintenance heavy it’s going to get if you keep doing things this way. Hard to tell without know where this is going. I’d personally avoid it.
While D&D is not without its limitations, it, at least, gives you an entire framework and functionality to work with. Sometimes you may want to escape those limitations, ofc. For example: here’s a version of draggable windows that does not utilise d&d and works fine:
I used it many times and it worked well enough. It’s using onMouseMove to get location.
Now - the real question: why are you using the Menu Anchor in the first place? Its child was never meant to be draggable! Making UMG do what is was never designed to do is a bit like shooting oneself in the foot. Try dragging native button to see what I mean…
If you want to pop new draggable windows, have a look at the link I posted. I’d never use the menu anchor for that. Not saying it couldn’t work, but I’d expect it to be fussy. And it seems to be.