Recent Windows WebView deprecation message FWIW

[dbadb]

I've recently noticed this message appearing in debug builds. I'm really not certain what import is may have for typical use-cases.

Warning: AddWebResourceRequestedFilter without SourceKind parameter is deprecated! It does not behave as expected for iframes.Please use AddWebResourceRequestedFilterWithRequestSourceKinds instead. For more information, please see https://go.microsoft.com/fwlink/?linkid=2286319 

[julianstorer]

Just had a quick look at this, but get the latest COM API that avoids the warning, I'd have to manually add 22 COM class declarations! Too much work to do right now, I'm afraid!

[dbadb]

I was just re-exploring this and have a quick question on your process for producing the windows interface. I understand this is a manual process? I see there is an IDL file in the webview github (eg: Microsoft.Web.WebView2.1.0.2957.106/WebView2.idl) and wonder if an IDL-to-boilerplate makes sense? I'm not volunteering yet, just exploring. :-) thx!

More background: I'm trying to fetch data from another site and since the origin of a WebView app is "weird", we get CORS errors from the server like

No 'Access-Control-Allow-Origin' header is present on the requested resource.

The usual fix for the problem is to intercept and modify response headers. In the Windows Webview2 case, there's a method: add_WebResourceResponseReceived and an associated Event definition. These aren't present in the current choc_WebView.h.

[julianstorer]

TBH can't remember what I used for the IDL conversion. The annoying bit about the function you need is that there are 22 intermediate classes that would all need to be added to get to the version that you want.. Could probably be automated and then pasted/cleaned up.

[dbadb]

Thanks for the pointers! I'll poke around some more and update this thread if I find anything useful.

[dbadb]

Hi Julian - here's an update on this thread.

As an experiment, I modified choc_WebView.h to use Microsoft's webview2.h header that is produced as a build artifact of their WebView2Samples repository here.

With a few changes to your pimpl code related to using __uuidof instead of getIID for QueryInterface(), it "just works". As you know, this is independent of the question of the loader DLL. It's theoretical value is merely to reduce the maintenance headaches for tracking interface changes into the future.

As described earlier, my goal is to intercept and filter response headers for non-locally-served requests and I'm now in a position to tinker with that.

Should you like to inspect the changes, you can find the branch here. NB: this was branched of your development branch since it appeared to have recent window-specific fixes.

Here are some potential gotchas/issue:

• this requires microsoft's "wil" package headers eg "wil/wrl.h", "wil/com.h", these appear to be licensed similarly to webview2.h
• if including wil and wrl, then I'm unclear on whether your com memory management code is redundant (but it seems to work anyway).
• i currently checked in the entirety of their wil subdir, made no attempt to whittle it down to its minimum.

I will update this thread when I have the results of the response-header filtering.

cheers, Dana

[dbadb]

So the good news is that the new webview2.h header has more than enough interfaces to evaluate my response-headers mini-project. Unless I'm missing something, I think it's definitely the way to go.

As for my headers-filtering project, this didn't pan out since Webvew2 provides view-only access to response-headers. (ICoreWebView2WebResourceResponseView)...

[dbadb]

And back to the originaldeprecation message at the top of this thread. I note that IID_ICoreWebView2_22 is the interface version that introduced the new method: AddWebResourceRequestedFilterWithRequestSourceKinds. The newest version of this interface is _27, fwiw.

[julianstorer]

With a few changes to your pimpl code related to using __uuidof instead of getIID for QueryInterface(), it "just works".

It might "just work" in visual studio, but not in mingw, which I also need to support. Otherwise, obviously I'd have just done it the easy way too!

[dbadb]

not sure I understand, but do defer to you. If the issue is only __uuidof, then there are certainly workaround where the interface ids are hard-coded within choc_WebView.h and not within the classes themselves. Are there other MINGW issues besides uuidof?

also: fwiw, it works with clang-for-windows too.

[julianstorer]

When I did this (a couple of years ago), I started with the regular microsoft header and had to do a bunch of things to make it work in MINGW, but I forget what they all were. I have got MINGW tests in CI to make sure it doesn't get broken.

But also, IIRC, the extra steps that a user had to take to get the correct official windows headers in the right place were also a problem. Having got to the point where using this class requires absolutely no other dependencies, I don't want to compromise on that.

[dbadb]

Gotcha! fwiw: I updated my branch to eliminate the use of uuidof.

Since I'm not currently interested in MINGW and don't have the time to install and validate, we'll leave it here. thx!

[dbadb]

FWIW: my choc/webview hobby app is up. Choc has been very helpful in developing it. Thanks for creating this excellent package! (see here for docs and downloads).