Unfortunately, besides updating the code to work with Google's latest
changes, commit 2a1aad2 introduced a bug when using the Microsoft
icon pack that prevented the widget from loading. Thus, this commit:
* Fixes that (there was no need for `getElementById('wob_tci').children[0]`
apparently)
* Besides checking for blobs in `src`, it also checks for image names,
since `wob_tci` (main icon) still contains a URL, not a blob
* Fixes `wob_tci` to update with proper icon when interacting with the
widget, for example when selecting a day with a different forecast than
the current conditions
* Simplifies some logic, seems the widget works fine without it
Hopefully this fixes the widget properly.
This basically undoes commit a8c7fba and properly fixes the issue:
it seems Google moved the images in a separate child `img` tag, under
what I was previously looking for. Furthermore, the src is not a URL
anymore, but directly the image encoded in base64. Fortunately, we
can match the last characters against images obtained from their 48px
and 64px endpoints. More details here:
https://github.com/valinet/ExplorerPatcher/discussions/755#discussioncomment-5353030
It seems Google has introduced a bug, where they do not change the
main image when changing to another day in the widget. Hopefully they
will fix it in the future.
It seems Google changed the widget and explicitly set a background
color, so this patch takes that into account and removes it.
Previously, the widget did not have a background, rather inheriting it
from the `body` element.
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.
This is so that we avoid a situation where the browser was looping on
trying to display the error page. Each navigation request was
erroring out, and the error said something along the lines of
"Your computer went to sleep". Indeed, this bug could be reproduced by
hibernating the computer and then waking it up - it seemed to occur
pretty frequently, especially on battery, when the power budget is more
constrained, and thus the speed of the PC as well. Hopefully, this
commit and the previous one addresses this issue.
Amrsatrio
Valentin Radu