How to implement a persistent side panel (MV2/MV3 style) using HEScript and secondary windows?

Hi everyone,
I am looking to implement a two-panel architecture in my ExeOutput application (Main Window + a persistent Side Panel). My goal is to replicate the core behavior of side panels found in modern browser extensions (both Manifest V2 background scripts and Manifest V3 sidePanel API design).
The key technical requirements for this architecture are:

1. Context/Process Isolation: The side panel must run in its own independent context. It should never reload or lose its state when the user navigates through different pages, clicks links, or refreshes the content in the Main Window.
2. Bi-directional Communication: There needs to be a seamless JavaScript-to-JavaScript communication bridge between both windows. The side panel must always "know" the current URL or DOM state of the main window and be able to interact with it.

In standard browsers, this is handled via background scripts (MV2) or service workers and the sidePanel API (MV3). Since ExeOutput leverages Chromium / WebView2, I want to achieve this behavior natively using the application wrapper, without building an actual .crx extension.
Could anyone guide me on the best way to achieve this using HEScript and window management in ExeOutput? Specifically:

• How should I properly configure a secondary window (Secondary Window or embedded panel) so it remains docked to the right side of the main window as a persistent Child Window?
• What is the most efficient way to pass messages from the Main Window's JavaScript (e.g., catching URL changes via window.onload) into HEScript (like UserMain), and then routing those messages via ExecuteHTMLScript into the side panel browser instance without triggering CORS or same-origin blockages?

Any architectural tips, best practices, or small HEScript code snippets demonstrating this multi-window communication flow would be highly appreciated.
Thanks in advance for your help!

---

This is very interesting; I hope you do not mind if I lurk and follow along.

Following up on my initial post, I have been thinking about how to approach this from a practical standpoint, both for a quick short-term solution and for a long-term architectural feature.
As a fast and immediate workaround, would it be possible to simply unlock native support for Manifest V3 (and Manifest V2 if the underlying engine version still allows it) inside ExeOutput? If we could just pass or package an unpacked extension folder that initializes with the engine, it would solve the immediate problem without requiring any new UI development on your end.
Looking at the bigger picture for future updates, what would be truly amazing is native support for a multi-area GUI architecture. Instead of treating the application as a single web browser window, ExeOutput could allow us to split the interface into distinct operational zones.
A great way to visualize this is the dashboard of a modern car. You have the main central screen where the user actively navigates, changes pages, or loads different URLs. At the same time, you have surrounding panels—like the speedometer or climate controls—that run continuously in their own isolated space. They never reload, they never lose state, but they are fully aware of what is happening on the main screen and adapt their display accordingly.
In web terms, this would mean having a main content area alongside one or more persistent side panels. The panels would run in their own background processes, completely unaffected by the main window refreshing or navigating to a new URL, yet they would always know the current URL or DOM state of that main window to sync data.
Would opening up the MV3/MV2 extension loading be feasible as a quick first step, and how do you see the possibility of a native multi-area dashboard architecture in future versions of ExeOutput?

Just to add some technical context regarding WebView2 capabilities, the official Microsoft Edge Developer documentation notes that the WebView2 SDK has fully promoted the WebView2 Worker APIs to stable (Phase 3) as of June 2026.
According to the release notes, WebView2 now officially supports lifecycle events and messaging interfaces (PostMessage / WebMessageReceived) for Service Workers, along with the AreWebViewScriptApisEnabledForServiceWorkers profile property.
Since Service Workers are the absolute core backbone of background scripts in Manifest V3, the fundamental engine infrastructure required to support MV3 extensions seems to be completely mature and available out-of-the-box in WebView2 now.
I think unlocking this feature or exposing the AddBrowserExtensionAsync method in ExeOutput would leverage what Microsoft has already built, making a native multi-area dashboard or extension support much easier to implement than creating a custom solution from scratch.
What are your thoughts on utilizing these native WebView2 Worker and Extension capabilities in ExeOutput?

It's a pity that this forum is so dead

One clarification on the engine first, because it changes which of your ideas are reachable now versus later. ExeOutput for PHP's internal browser is WebView2-based, so you are right that WebView2 is the relevant platform here. The catch is that the specific pieces you cite, AddBrowserExtensionAsync and the WebView2 Worker / Service Worker APIs promoted in June 2026, are not yet exposed in ExeOutput. So today there is no switch that loads an unpacked MV2/MV3 extension folder into the engine. That capability is under study for a future update, precisely because, as you point out, WebView2 now provides the underlying infrastructure.

On the two bigger asks, native browser-extension (MV3) loading and a native multi-area "dashboard" architecture: both are under study for a future version. Your point that WebView2 now ships the Worker and extension infrastructure is well taken, and it is exactly what makes this worth looking at on our side.