Thanks for pointing that out but <a target=“_blank”> is not broken and was disabled ON PURPOSE. In fact all popups have been explicitly disabled by the plugin AS THE INTENDED FUNCTIONALITY. The only exception to this is the Chrome Dev Tools popup which the plugin allows in development builds.
The point of this plugin is to develop web-based user interfaces and to communicate with these browser instances via JSON using the OnBroadcast event. When you click <a target=“_blank”> the engine will automatically create a new window but it is not a WebUI widget and you have no OnBroadcast event to communicate with the popup. Moreover popup windows in UE4 are a little buggy when closing the popup as they break the parent web browser.
So popups will not be supported in the plugin. However if you absolutely need to get popups working then you can edit the source code and compile the plugin yourself. You can see in the OnBeforePopup method that it always returns TRUE which indicates that the popup was handled:
Again the only exception to this is when the URL matches the Chrome Dev Tools in which case it returns FALSE and UE4 will create a popup. So if you remove the code in this function and just have it always return FALSE then you can achieve legacy popup functionality in the engine. There are instructions in the documentation on how to compile the plugin yourself.
Now the INTENDED FUNCTIONALITY is for you to use the global ue4(…) helper function to relay information to the engine. That means if you want to create a popup for some reason (even though it really is an awful design strategy for games) you should bind an OnClick event in JavaScript to the <a> tag such that you can trigger the OnBroadcast event and handle the popup yourself. There really is no reason to be using <a target=“_blank”> if developing your own custom user interface.
However if you are loading a website that uses <a target=“_blank”> (or any similar situation where you do not have control over the interface) then you might actually need to respond to these popup events. So while that function always returns TRUE you can see it also always triggers the OnBeforePopup event of the parent widget allowing you to respond to these events. However it seems this event was not relayed to UMG (blueprints) meaning you cannot access it without extending the Slate widget yourself.
Therefore I’ll make a note to add this event to the UMG widget allowing for access in blueprints to the OnBeforePopup event. But as mentioned popup functionality itself will always remain disabled in this plugin.