Change of behavior in web browser plugin causes crash

On Mac, the behavior of the browser plugin has change in version 5.7 and is causing a crash in our existing code. We are using the Web Browser plugin for authentication with the following workflow (pseudo code below) : An IWebBrowserWindow is created, where the user can log in. Once it succeeds, the browser is forwarded to a new page that has the access code. We use IWebBrowserWindow->OnUrlChanged() to retrieve this code and then close the window using FSlateApplicationBase::Get().RequestDestroyWindow.

Starting 5.7 on Mac, destroying the window fails this check. It appears that on Windows the lambda provided to OnUrlChanged is called in GameThread, so there is no crash. On Mac, in version 5.6, this code is called in a thread named crBrowserMain, which also works. However in version 5.7 this is called in an unnamed thread and crashes.

Is this a bug or the expected behavior from now on?

auto window = SNew(SWindow).ClientSize(FVector2D(900, 700)).IsTopmostWindow(true);
 
FCreateBrowserWindowSettings windowSettings;
windowSettings.InitialURL = *AuthorizeURL;
 
auto webBrowserWindow = IWebBrowserModule::Get().GetSingleton()->CreateBrowserWindow(windowSettings);
 
webBrowserWindow->OnUrlChanged().AddLambda([this, window](FString NewUrl) {
 
 // get access code
 
 FSlateApplicationBase::Get().RequestDestroyWindow(window);
 }
});

[Attachment Removed]

Hi,

Doing Slate things outside of the game thread has never really been supported (outside of a special case with the Slate loading thread) so I’d recommend at least pushing that call to RequestDestroyWindow to the game thread:

webBrowserWindow->OnUrlChanged().AddLambda([this, window](FString NewUrl) {
 
 // get access code
 
  AsyncTask(ENamedThreads::GameThread, [this, CapturedUrl]()
        {
            // Now safely on the Game Thread
            // Re-validate state in case window was already destroyed
            if (BrowserSlateWindow.IsValid())
            {
                FSlateApplicationBase::Get().RequestDestroyWindow(window);
            }
		}
 }
});

I’ll flag it with the team, as it might make sense for us to just invoke the OnUrlChanged callback from the game thread to be sure you don’t run into issues like this.

Best,

Cody

[Attachment Removed]