[BUG] Unclosable Built-in Web Browser leading to RAM hogging

[ninjaloose]

Please confirm these before moving forward

• I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
• I have tested that this issue has not been fixed in the latest (beta or stable) release.
• I have checked the FAQ section for solutions.
• This issue is about a bug (if it is not, please use the correct template).

UniGetUI Version

2026.2.5

Windows version, edition, and architecture

Microsoft Windows 10.0.19045 Professional X64

Describe your issue

WebView has invaded Uniget unfortunately, I'm not sure why we need a browser in there at all, but the current issue I have is that once it's open and chugging down on my precious RAM, it doesn't have any way to be closed.

Steps to reproduce the issue

1. Open Uniget
2. Observe system RAM usage
3. Back in UniGet - Click "More" ( at the bottom left)
4. Click "Help" or "Release Notes" to spawn WebView/browser (do this more times for additional instances)
5. Try to close this browser from within UniGet (you will find it's not possible)

Additionally Pressing More>Release Notes, then Help, then release notes again shows a blank page with nothing on it, but will still spawn more processes after every click on either of those two links, the UniGetUI Log shows weirdness there.

UniGetUI Log

This log has been trimmed for privacy and relevancy

[18/07/2026 1:54:45 AM]    __  __      _ ______     __  __  ______
                          / / / /___  (_) ____/__  / /_/ / / /  _/
                         / / / / __ \/ / / __/ _ \/ __/ / / // /
                        / /_/ / / / / / /_/ /  __/ /_/ /_/ // /
                        \____/_/ /_/_/\____/\___/\__/\____/___/
                            Welcome to UniGetUI Version 2026.2.5
[18/07/2026 1:54:45 AM]   
[18/07/2026 1:54:45 AM] Build 107
[18/07/2026 1:54:45 AM] UI Framework: Avalonia
[18/07/2026 1:54:45 AM] Data directory C:\Users\username\AppData\Local\UniGetUI
[18/07/2026 1:54:45 AM] OS: Microsoft Windows 10.0.19045
[18/07/2026 1:54:45 AM] Process arch: X64 (OS: X64)
[18/07/2026 1:54:45 AM] Runtime: .NET 10.0.10
[18/07/2026 1:54:45 AM] Loaded language locale: en
[18/07/2026 1:54:45 AM] Elevated: False
[18/07/2026 1:54:45 AM] Packaged (MSIX): False
[18/07/2026 1:54:45 AM] Args: (none)
[18/07/2026 1:54:45 AM] DXGI hardware GPU detection took 4.8 ms; hardware GPU: True
[18/07/2026 1:54:45 AM] Command cargo-binstall.exe was not found on the system
[18/07/2026 1:54:45 AM] Unable to retrieve secret for resource 'UniGetUI/GitHubAccessToken': Element not found.
                        
                        Cannot get credential from Vault
[18/07/2026 1:54:45 AM] Unable to retrieve secret for resource 'UniGetUI/GitHubAccessToken': Element not found.
                        
                        Cannot get credential from Vault
.
.
.
[18/07/2026 1:54:49 AM] Found 0 installed packages from vcpkg
.
.
.
[18/07/2026 1:55:05 AM] [Telemetry] Hard crash posting to unigetui_activity_events
[18/07/2026 1:55:05 AM] System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
                         ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host..
                         ---> System.Net.Sockets.SocketException (10054): An existing connection was forcibly closed by the remote host.
                           --- End of inner exception stack trace ---
                           at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError, CancellationToken) + 0x3d
                           at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16) + 0x58
                           at System.Net.Security.SslStream.<EnsureFullTlsFrameAsync>d__170`1.MoveNext() + 0x1c2
                        --- End of stack trace from previous location ---
                           at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16) + 0x23
                           at System.Net.Security.SslStream.<ReceiveHandshakeFrameAsync>d__160`1.MoveNext() + 0x193
                        --- End of stack trace from previous location ---
                           at System.Net.Security.SslStream.<ForceAuthenticationAsync>d__159`1.MoveNext() + 0x4ec
                        --- End of stack trace from previous location ---
                           at System.Net.Http.ConnectHelper.<EstablishSslConnectionAsync>d__2.MoveNext() + 0xdc
                           --- End of inner exception stack trace ---
                           at System.Net.Http.ConnectHelper.<EstablishSslConnectionAsync>d__2.MoveNext() + 0x46e
                        --- End of stack trace from previous location ---
                           at System.Net.Http.HttpConnectionPool.<ConnectAsync>d__53.MoveNext() + 0x5e7
                        --- End of stack trace from previous location ---
                           at System.Net.Http.HttpConnectionPool.<CreateHttp11ConnectionAsync>d__81.MoveNext() + 0x267
                        --- End of stack trace from previous location ---
                           at System.Net.Http.HttpConnectionPool.<InjectNewHttp11ConnectionAsync>d__80.MoveNext() + 0x2ca
                        --- End of stack trace from previous location ---
                           at System.Threading.Tasks.TaskCompletionSourceWithCancellation`1.<WaitWithCancellationAsync>d__1.MoveNext() + 0xf9
                        --- End of stack trace from previous location ---
                           at System.Net.Http.HttpConnectionPool.<SendWithVersionDetectionAndRetryAsync>d__52.MoveNext() + 0x2f9
                        --- End of stack trace from previous location ---
                           at System.Net.Http.RedirectHandler.<SendAsync>d__4.MoveNext() + 0x1d5
                        --- End of stack trace from previous location ---
                           at System.Net.Http.DecompressionHandler.<SendAsync>d__16.MoveNext() + 0x2db
                        --- End of stack trace from previous location ---
                           at System.Net.Http.SocketsHttpHandler.<<SendAsync>g__CreateHandlerAndSendAsync|115_0>d.MoveNext() + 0x10e
                        --- End of stack trace from previous location ---
                           at System.Net.Http.HttpClient.<<SendAsync>g__Core|83_0>d.MoveNext() + 0x371
                        --- End of stack trace from previous location ---
                           at UniGetUI.Interface.Telemetry.TelemetryHandler.<PostToOpenSearchAsync>d__30`1.MoveNext() + 0x2a4

Package Managers Logs

Manager WinGet with version:
System WinGet (CLI) Version: v1.29.280
Using Native WinGet helper (COM Api)
Activation mode: packaged COM registration
Activation source: system COM registration

——————————————————————————————————————————

Logged native task on manager Winget. Task type is ListSources
Process start time: 18/07/2026 1:54:46 AM
Process end time:   18/07/2026 1:54:46 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————
Logged native task on manager Winget. Task type is ListInstalledPackages
Process start time: 18/07/2026 1:54:49 AM
Process end time:   18/07/2026 1:54:57 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————
Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\james\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity "
Process start time: 18/07/2026 1:54:49 AM
Process end time:   18/07/2026 1:54:50 AM

-- Process STDOUT
 ...

Return code: SUCCESS (0)

——————————————————————————————————————————
Logged native task on manager Winget. Task type is OtherTask
Process start time: 18/07/2026 1:54:49 AM
Process end time:   18/07/2026 1:54:54 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————
Logged native task on manager Winget. Task type is ListUpdates
Process start time: 18/07/2026 1:54:50 AM
Process end time:   18/07/2026 1:54:59 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————
Logged native task on manager Winget. Task type is LoadPackageDetails
Process start time: 18/07/2026 1:54:59 AM
Process end time:   18/07/2026 1:54:59 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————
Logged native task on manager Winget. Task type is LoadPackageDetails
Process start time: 18/07/2026 1:54:59 AM
Process end time:   18/07/2026 1:55:00 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————
Logged native task on manager Winget. Task type is LoadPackageDetails
Process start time: 18/07/2026 1:55:00 AM
Process end time:   18/07/2026 1:55:00 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————
Logged native task on manager Winget. Task type is LoadPackageDetails
Process start time: 18/07/2026 1:55:00 AM
Process end time:   18/07/2026 1:55:01 AM

-- Task information
 ...

The task reported success

——————————————————————————————————————————

Relevant information

I don't think we should have browsers within software that is not itself designed to be a browser, purely from a security standpoint, especially for such a simple use case as linking to Release Notes or the help page.

Screenshots and videos

1) Before - 270MB

2) After pressing each link once - 380MB + 454MB

3) After some more pressing - 345MB + 564MB

[GabrielDuf]

Hi ninjaloose,

I just merged a PR that improves how the WebView is disposed of when switching pages. This should prevent the extra WebView instances from lingering, and the fix will be included in the next release.

Regarding the comment about WebView "invading" the application: UnigetUI has used WebView for the Help and Release Notes pages since before the Avalonia migration, so this behavior isn't new. However, the disposal issue you reported is valid, and the recent changes should address it.