I investigated an issue with the WidgetComponent in 5.7.1, hence i can’t confirm the same issue applied for 5.6.1, it was behaving the same.
Basically the WidgetComponent in the function RegisterWindow() is checking the condition (Widget && !Widget->IsDesignTime()) which may not be true in build, by not going into that function, the parent of the virtual window is never set, and because of that, the WidgetPath is resulting in a truncated path, since it’s going over the viewport -> window in the chain and can’t validate that the window have the viewport as parent. This is breaking at least the drag & drop feature, but might be wider than that.
I’m sure there is a better way to handle the fix, but since in editor the fast path is not used for now, here is the modifications i made to make it works
Steps to Reproduce
Create a widget component with a widget allowing drag & drop, it will work in editor because it’s using the slow path but in build the fast path is broken
I set up a minimal drag & drop test using a WidgetComponent in both UE 5.6 and 5.7. I placed an actor in the level with a WidgetComponent that allows for drag & drop. This operation behaves correctly for me in the Editor and in packaged builds. In my tests the drag visual appears as expected in both cases.
Could you please share either a small repro project, or more information about your WidgetComponent configuration and any additional steps required to trigger the issue on your side?
That’s interesting, though it was going to be more of an issue since this bug is breaking the fast path, but i guess something in our project trigger the fact that the widget is null when we get there, i will try to reproduce the issue with a smaller asset if i can, meanwhile here is the configuration of the widget component we have that differ from default
[Image Removed]the widget itself have not much in it
[Image Removed]Maybe it is related to a specific flow we have, but the fix seems quite good to me, outside of editor, this condition doesn’t make much sense, at least unless someday the editor uses that fast path as well, the fact widget is null or not doesn’t matter much when setting the virtual window parent to the viewport
Let me know if theses configurations are enough to trigger it, otherwise will see if i can extract simpler assets and still have the bug when i have some time
Also, if that helps, i was able to reproduce the issue using the standelone (mobile and not mobile) from the editor and IOS builds, i did not try any other platforms or configuration so i can’t tell if that issue should appear in other platforms builds
Thanks for all the extra details. I’ve now been able to reproduce the issue consistently on my side on a Windows machine. I noticed the following:
In PIE, drag and drop works correctly.
In a Standalone Game window launched from the editor, drag and drop fails.
In a packaged build, drag and drop also fails in the same way.
The issue occurs when the widget is set dynamically at runtime (via CreateWidget and then SetWidget on the WidgetComponent). However, when the Widget Class is assigned directly on the component in the actor placed in the level (so the widget is created as part of the component’s initialization, not via SetWidget at runtime), drag and drop works correctly in Standalone/game builds.
It appears the SVirtualWindow isn’t being parented correctly in the runtime path when the widget is swapped dynamically.
Regarding your workaround: I tested it in a recent Main source build, and noticed it doesn’t cover the case where Standalone Game is launched from the editor. To handle this scenario, I made a small adjustment to your proposed workaround:
void UWidgetComponent::RegisterWindow()
{
if ( SlateWindow.IsValid() )
{
if (!CanReceiveHardwareInput() && FSlateApplication::IsInitialized() )
{
FSlateApplication::Get().RegisterVirtualWindow(SlateWindow.ToSharedRef());
}
UWorld* LocalWorld = GetWorld();
#if WITH_EDITOR
if (!Widget || Widget->IsDesignTime())
{
const bool bIsGameWorld = LocalWorld && LocalWorld->IsGameWorld();
if (!bIsGameWorld)
{
// do not early-out for game worlds (PIE / Standalone-from-editor).
return;
}
}
#endif
if (LocalWorld && LocalWorld->IsGameWorld())
{
if (UGameInstance* GameInstance = LocalWorld->GetGameInstance())
{
if (UGameViewportClient* GameViewportClient = GameInstance->GetGameViewportClient())
{
SlateWindow->AssignParentWidget(GameViewportClient->GetGameViewportWidget());
}
}
}
}
}
I’ll go ahead and register this as an internal bug. In the meantime, feel free to continue using your workaround or the adjusted version above. I’ll follow up once the issue has been logged.
Glad it helped. I’ve submitted the bug internally for the engime team to review. You’ll be able to track its status once it becomes public at the following link: Unreal Engine Issues and Bug Tracker (UE\-356891)
If there’s anything else you need on this case, please feel free to let me know. Otherwise, I’ll go ahead and close it.
