WebView2 with every install

Hi. As I understand it, WV2 is included with (and updated by) Win11 automatically, so WW probably shouldn’t be installing it on Win11, right? But it does.

It should be on Win 8.1/10 only that you would do that, if needed.

Reference:

The Evergreen WebView2 Runtime will be included as part of the Windows 11 operating system. Various WebView2 apps have installed the Evergreen Runtime on devices with an operating system prior to Windows 11. However, some devices might not have the Runtime pre-installed, so it’s a good practice to check whether the Runtime is present on the client.

Before your app creates a WebView2, the app should check whether the WebView2 Runtime is present (either by checking a registry key or by calling an API) and install the Runtime if it is missing. The app can do this check when installing or updating your app (recommended), or at app runtime. To check whether the Runtime is present, see Deploying the Evergreen WebView2 Runtime, below.

1 Like

Good idea. I updated the Weather Watcher installer to check if the WebView2 Runtime needs to be installed before executing the WebView2 installer.

2 Likes

Thanks. That was quickly remedied.

On a related note, some months later, so pertaining to very recent versions, possibly only the latest, I started noticing weird system pauses for several seconds that never used to happen. It’s only 2 or 3 times a day, I think, so it was difficult to catch on to what it was, but I eventually found it to be msedgewebview2.exe pushing the CPU all the way up for those seconds, really monopolizing the system in a surprising way (maybe the process has top priority).

It’s not a weather “refresh” that does this though (I tried that manually as a test), and that happens way more than 2-3 times a day anyway. Do you know what might be going on with msedgewebview2.exe related to WW a few times a day that would be very resource intensive? I know it’s something that happens automatically, since I’m never touching WW at the time.

Thanks

I haven’t experienced this issue myself (nor has anyone else reported it).

Two possibilities:

  • There could be a bug in the version of WebView2 Runtime that’s installed with Weather Watcher. If this is the case, it seems all Weather Watcher users (those running Windows 11 at least) would have run into this issue by now.

  • Perhaps you’re running other applications that are using the WebView2 Runtime. Many other Windows applications have probably been upgraded to use the WebView2 Runtime by now since Internet Explorer has been discontinued by Microsoft.

I think it’s updated regularly by Windows though, about as frequently as Chromium is, which is often. Mine is dated the 15th.

On the other applications, that’s quite possible. I know Outlook, for example, has started to use it for a few pieces of itself. But the last time this happened I was ready for it and quickly brought up a task manager which showed the msedgewebview2.exe process and WW in the same branch, so I’m pretty sure it’s related to WW in this case.

I did notice in the temp dir that there’s a WeatherWatcher, under that a EBWebView, and under that (at the moment) about 72MB and 338 files, essentially a mini Chromium. This is probably normal for the way the runtime works though and I don’t know if it’s involved. Maybe the performance hit comes in when that needs to be refreshed (not really sure if that’s a thing, so am just guessing).

Can you try snapping a screenshot of that if it happens again?

Yes, that is normal.

Yes, I will. I wonder if the reason this seems to have not happened recently (aside from it maybe knowing that I’m onto it) is that Microsoft is on holiday break and so isn’t pushing updates for the runtime. That may be what sets things off. With what looks to be four sets of them on this system (Edge stable, Edge dev, Edge core, EdgeWebView), all containing the binary in question, there’s lots of opportunity.

1 Like

Hi, just updating to say that a) this has resumed in the new year now that MS is updating its Edge components again, and b) I’m still trying to be fast enough to take a screenshot (recall that the system is slowed during these events, too, which doesn’t make that any easier).

But I had another thought: is there a way to limit WW’s use of the components, or at least identify specifically which pieces use it and when? If so, maybe I could affect the matter by adjusting some of the WW settings.

Setting an alternate map URL here will disable all WebView2 activity:

OK, I’ll try that to see what it effect it might have.

I didn’t know that feature existed. I wonder in general why anyone would want a never-changing image for radar?

That’s possible. But, it’s more likely that people are using this feature to display routinely updates maps with a static URL – like this:

Definitely, though it’s not exactly widely known. I found how to do it here, of all places:
https://forum.kodi.tv/showthread.php?tid=253905&pid=2201526#pid2201526

I’ve been using it set that way this week, and despite a couple EdgeWebView updates in the interim, all has been well. What’s more, the map is actually quite good, so that’s a bonus.