UEWebBrowser-WebNativeBrowser High Performance Browser
When you need complex tables, charts, dashboards, forms, or maps inside Unreal, the choice is rarely “UMG or Slate or Web” — it is about splitting the interface by nature. UMG is great for game HUDs and engine-bound widgets. Slate is great for editor tooling. Web is the pragmatic choice for data-heavy, business-style UI, because the ecosystem (React/Vue, chart and table libraries, theming, browser DevTools) is already mature.
Opening a web page inside UE is the easy part. Making it behave like a native application is where the real work is. Here are the engineering gaps I had to solve while building a browser widget for UE 5.1–5.8 on Windows and Linux (x86_64 + ARM64).
1. Input focus and IME
Chromium and UE each own their input stack. Focus must be transferred explicitly between the web page and the 3D viewport, and things get noticeably harder with Chinese IME composition — the candidate window, composition events, and focus switches all need dedicated handling.
2. File upload and download
A packaged UE application has no browser file dialog. The plugin has to provide its own picker, a user-configurable download path, and real-time progress callbacks back into the page.
3. iframes and cross-origin
Existing web systems often embed maps, video walls, or internal OA pages through iframes. Cross-origin policy and CSP need to be handled or the embedded content silently breaks.
4. Permissions
Camera, microphone, and geolocation have no browser permission popup in a packaged app. Permissions must be centrally managed with a sensible fallback policy instead of “allow everything”.
5. Cross-platform validation
Something that works in a Windows browser may fail in a packaged Linux build. Fonts, video decoding, WebGL, IME, and GPU drivers each need separate validation per platform. This is where most “it works on my machine” bugs come from.
6. Performance
The UE scene and the web page share GPU resources. The common bottlenecks are high-frequency JS-to-UE messages, large DOM trees, and video streams. A shared-memory texture path (no CPU copy) and a typed message channel made the difference in practice.
7. Debugging and operations
Packaged apps have no DevTools, and logs are split between the UE process and the browser process. Correlating a JS error with a UE-side event requires a unified logging story.
Notable engineering outcomes
A few decisions stood out during development:
- Zero-copy rendering — the web content is transferred between the browser process and UE through GPU shared memory, so there is no CPU copy or readback. This is what keeps 4K dashboards and video smooth inside the scene.
- High-throughput message channel — instead of ExecuteJavaScript string splicing, JS and UE talk over a typed message channel (function name + message body). In practice it sustains roughly 10k messages in ~220ms, and the per-frame dispatch budget is capped so the game thread never stalls.
- Cross-platform from day one — the same code path runs on Windows, Linux x86_64, and Linux ARM64, with a per-platform validation matrix for fonts, video, WebGL, IME, and GPU drivers. Chinese IME on Linux was the hardest single item.
- Multi-instance isolation — multiple widgets can each run their own web content in the same process with isolated profiles and DevTools, which matters for dashboards that embed several pages at once.
- Pixel Streaming friendly — because the widget lives inside the UE process, it also works when the project is streamed remotely through UE’s Pixel Streaming, so the same UI reaches browser clients without extra work.
- Alpha hit-testing and click-through — transparent overlays can pass input through to the 3D scene underneath, instead of being an opaque rectangle that swallows all clicks.
I wrote up the approach and a reference implementation here:
Happy to discuss the engineering details — especially the input-focus and cross-platform parts, which took the longest to get right.