If `w.Show()` fails, the WebView window remains open even if `w.Destroy()` is called

[bminer]

To reproduce:

• Call w.Show or w.ShowBrowser
• Ensure that the target URL does not actually allow WebUI to connect properly (i.e. no /webui.js endpoint)
• Show will return an error (correct behavior), but the window cannot be closed
• Call w.Close() or w.Destroy() and notice that the window will remain open. In fact, even ui.Exit() or ui.Clean() have no effect on the "orphaned" window.

This could be an issue with the WebUI library... or perhaps WebView... I'm not sure.

go version go1.24.0 windows/amd64
github.com/webui-dev/go-webui/v2 v2.4.3-0.20250107141857-41f2f2df30c6
github.com/webui-dev/webui v0.0.0-20250406153953-7adbdc482258

[AlbertShown]

This is normal behavior for web browser window as WebUI can't execute JavaScript to close the window if there is no webui.js. While for WebView it should definitely get closed in all scenarios.

[AlbertShown]

We tried to get the window PID but it's not guaranteed to be always the right one as each browser create many childs process differently, and one of them is the WebUI window we are looking for.

WebUI is put on the shoulders of giants (web browsers) to provide the best and latest web technologies (JS, WebAssembly, HTTPS, HTML5...) but at cost of not owning the window.

[bminer]

This is normal behavior for web browser window as WebUI can't execute JavaScript to close the window if there is no webui.js. While for WebView it should definitely get closed in all scenarios.

Yeah, I was mostly referring to WebView2.

We tried to get the window PID but it's not guaranteed to be always the right one as each browser create many childs process differently, and one of them is the WebUI window we are looking for.

Unfortunate. One workaround I have used is double checking to ensure the HTTP server to which the web browser (or WebView) will connect is available and responding with 200 OK, but this also does not guarantee that the WebJS bridge (i.e. webui.js) is loaded.

[AlbertShown]

not guarantee that the WebJS bridge (i.e. webui.js) is loaded.

You can try if (typeof webui !== 'undefined')
Docs: https://webui.me/docs/2.5/#/?id=javascript-isconnected

to ensure the HTTP server to which the web browser (or WebView) will connect is available

I think that should work if you know exactly the server port, for example when you set a manual port that WebUI should use

[bminer]

Would still be nice if you could reliably close the window (i.e. WebView) if a connection is never established, but I can definitely understand the difficulty in that, especially in Windows.

[AlbertShown]

It should be in WebView mode, if it does not that means it's a bug then. I will check that later next week.

[bminer]

Yeah, sorry, I can definitely understand being unable to control the browser window, but this bug is mostly about WebView.