Webviews are still not properly closed

[akuznecov]

New sub process/thread is created for WebView2 on every item lookup and not closed until application exit
It could accumulate huge pile of memory on aggressive items inspection

Sidekick app version: beta 2024.12.20.608

Related issue/pr: #290 #298

[Theblackcat98]

I'd like to confirm I'm also having the same issue and noticed it after invisible window frames started to show up and never close.

In the screenshot, I opened Sidekick, then minimized, then opened again from the hidden icons in the start bar. Hence the 2 window frames plus the visible settings pane.

[domialex]

@akuznecov @Theblackcat98
Can you still reproduce this bug with the latest beta?

[leMicin]

It can be reliably triggered by price checking another item while having the trade window opened. @domialex found this: dotnet/maui#26746

[akuznecov]

@akuznecov @Theblackcat98 Can you still reproduce this bug with the latest beta?

Hello @domialex, unfortunately yes, it still reproducible with 2024.12.26.118

[KeterSCP]

@leMicin the problem is not with DisposeAsync, but with calling EnsureCoreWebView2Async on the wrong thread (thread pool thread):

This async lambda is explicitly pushed on the thread pool via Task.Run, and it's exception is swallowed and ignored (the problem would be easier to spot if the exception was at least logged and not completely ignored).

Documentation for the webview2 states that:

Unless previous initialization has already failed, calling this method with a different environment after initialization has begun will result in an ArgumentException

That's why it is failing on thread from thread pool - because it was initially initialized on the UI thread.