It seems that either the web page, either something in Microsoft's
WebView2 implementation changed so that when
`ICoreWebView2::NavigationCompleted` is fired, the elements of interest
on the page are not ready, which causes all this mess, as you can tell.
The solution for now was to delay the execution of my scripts, which
seemed to have gotten rid of the problem for now. I don't particularly
like the solution, I'd of course want something more robust, but I
guess these are the pitfalls when you do not control the entire
ecosystem...
A nasty bug was sometime occurring where both explorer and the widget
host process could hang; this often happened when explorer was
restarted. The reason this happened was because the widget host
process could hang waiting for the "Lock_EPWeather_Instance" lock. This
was a global lock that made sure only one instance of the widget could
be created.
The idea of the global "Lock_EPWeather_Instance" lock was, of course,
pretty bad, but I chose it because I couldn't figure out/didn't want to
deal with passing an EPWeather "this" instance to WebView2 or
NetworkListManagerEvents functions. Bad decision.
This patch addresses this bug, by providing a generic object
which holds a reference to EPWeather "this" on which I build event
handlers for WebView2 and so on. Since these now contain this
reference, they cannot be static anymore, thus I switched to dynamically
allocating them and managing them throughout their lifetime using,
of course, reference counting. This is the proper solution.
Thus, this bug and any similar ones should now be fixed.
