Any thoughts on WebView2 support for Dolphin?

[cDemersMitSci]

With the end of support for Internet Explorer the IWebBrowser2 interface (which uses Internet Explorer) is already problematic, and will no doubt eventually be totally useless. I presume it won't work at all in Windows 11.

Has anyone looked at implementing WebView2 https://docs.microsoft.com/en-us/microsoft-edge/webview2/get-started/win32 support for Dolphin? This looks like the intended replacement for IWebBrowser2 . It uses Microsoft Edge. Unfortunately it is more complicated to get working.

I found a type library in the NuGet package https://www.nuget.org/packages/Microsoft.Web.WebView2 . I used the ActiveX component Wizard to create the classes. However, it looks like there is a bit of fancy dancing required to create an instance. It seems we need to call a CreateCoreWebView2EnvironmentWithOptions() function with a callback. I can't find an implementation of CreateCoreWebView2EnvironmentWithOptions method in the generated code.

Does anyone have any thoughts or suggestions about where to go with this? Is this reasonable to approach from Smalltalk, or should we consider using an external C++ helper? I have the example working in C++, but don't know how to translate this to Dolphin.

[rjsargent]

There was a very similar thread on the VA Smalltalk forum in the past week. While the technology implementation is not transferable, the issues ought to be similar.

…

On February 15, 2022 10:13:30 PM PST, Chris Demers ***@***.***> wrote: With the end of support for Internet Explorer the IWebBrowser2 interface (which uses Internet Explorer) is already problematic, and will no doubt eventually be totally useless. I presume it won't work at all in Windows 11. Has anyone looked at implementing WebView2 [https://docs.microsoft.com/en-us/microsoft-edge/webview2/get-started/win32](url) support for Dolphin? This looks like the intended replacement for IWebBrowser2 . It uses Microsoft Edge. Unfortunately it is more complicated to get working. I found a type library in the NuGet package [https://www.nuget.org/packages/Microsoft.Web.WebView2](url) . I used the ActiveX component Wizard to create the classes. However, it looks like there is a bit of fancy dancing required to create an instance. It seems we need to call a CreateCoreWebView2EnvironmentWithOptions() function with a callback. I can't find an implementation of CreateCoreWebView2EnvironmentWithOptions method in the generated code. Does anyone have any thoughts or suggestions about where to go with this? Is this reasonable to approach from Smalltalk, or should we consider using an external C++ helper? I have the example working in C++, but don't know how to translate this to Dolphin. -- Reply to this email directly or view it on GitHub: #1156 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[cDemersMitSci]

Thanks, that was helpful. I found the discussion you mentioned here: https://groups.google.com/g/va-smalltalk/c/pE1vRxo9GIc .

[blairmcg]

I did look at this briefly ages ago, but it looked like it would be quite a lot of effort. You inspired me to look at it again, and it appears I was wrong:

I just posted this from a Dolphin hosted Edge browser.

[blairmcg]

I've merged it in so you can try it. Bear in mind that:

• It is very minimal now fairly complete. Easily complete enough to replace, and indeed improve, all the existing uses of IE in the base image. It works well.
• You will need to install the runtime and WebView2Loader.dll (x86) has to be on the path somewhere Dolphin will find it. I just copied one into the repo directory where I work. The loader is now in the repo (in LFS).
• I didn't even bother to read the more than the first few lines of the acres of verbiage there is about distributing the the runtime. Distributing the runtime with an application may be required. When not present the view will display a link to the relevant Microsoft page to install it.

[cDemersMitSci]

Sorry for the delayed response, got sent down a different rabbit hole for a bit.

This is very excellent! Awesome work Blair. I got it installed and it works great.

The old interface allowed access to the DOM of the browser. As I understand it that isn't exposed in WebView2, however JavaScript can be executed which can access the DOM. The tricky thing is that the JavaScript is executed asynchronously.

I added a WebView2SynchronousHandler class as a helper and got the following to work:
`
wv := URLPresenter show: 'WebView2'.
wv value: 'https://github.com/DolphinSmalltalk/Dolphin'.

"Wait for it to load"

webviewWindow := wv view instVarNamed: 'webviewWindow'.
imp := WebView2SynchronousHandler new.
handler := ICoreWebView2ExecuteScriptCompletedHandler on: imp.
webviewWindow executeScript: 'document.getElementById("branch-select-menu").innerText' handler: handler.
imp await.
"or"
imp awaitTimeoutSeconds: 5.
`

A helper method called executeScriptSync: could be added to ICoreWebView2. Is there interest in having synchronous JavaScript support? Does this convention seem reasonable or would a different approach be better?

[blairmcg]

I did experiment with running scripts, so there is an async abstraction already. I imagine you found this, but for the benefit of others the model is that one provides a callback block that is executed when the async operation completes, e.g:

wv := URLPresenter show: 'WebView2'.
wv value: 'https://github.com/DolphinSmalltalk/Dolphin'.
"Don't use #when:perform: when writing code in a class; use when:send:to:with:"
wv when: #domContentLoaded: perform: [:args |
	wv view webview 
            executeScript: 'document.getElementById("branch-select-menu").innerText'
            thenDo: [:hr :json |  MessageBox notify: 'Inner text: ', json]]

This shows a couple of things:

• Waiting for the DOM to be available - there are a number of status events such as domContentLoaded:, navigationCompleted:, etc, that might be relevant. The events are listed in WebView2View class>>webview2Events. They are named after the underling events so can be related back to the MS docs fairly easily, e.g. domContentLoaded: is for ICoreWebView2DomContentLoadedEventHandler. Some of these are demo'd in the various uses in Dolphin already, and the Simple Web Browser sample logs all the events to the transcript, which can help in understanding when they are triggered.
• Using the executeScript:thenDo: method (defined on ICoreWebView2, but there should be a forwarder on WebView2View really) to execute a script with a completion callback block.

The old interface allowed access to the DOM of the browser. As I understand it that isn't exposed in WebView2, however JavaScript can be executed which can access the DOM.

Yeah, I guess that is because the browser is running out-of-process. Fine-grained interaction with it (such as directly manipulating the DOM node-by-node) would likely not perform well if they'd provided direct access to the DOM. It probably makes sense that any significant DOM code be converted to javascript to run in the browser to make any interaction with the host program much more course grained.

A helper method called executeScriptSync: could be added to ICoreWebView2. Is there interest in having synchronous JavaScript support?

Yes, absolutely. When writing new code, I think it would probably be better to try and follow the event driven or callback model as above. It is the simplest fit, and capable of providing a better user experience without long periods of the application UI not responding. However the event-driven approach is going to require quite a different application design, and so is probably not going to fit easily into existing code that was using IE before. For the latter case alone the kind of synchronous mechanism you suggests makes sense. I didn't want to go there because I didn't have any scenarios to hand among the existing Dolphin code to help me prove it out (... or actually maybe I did have, but didn't realise: SUnits).

I don't think I have the experience to judge in the abstract whether your approach is the best available. Just go with it, and see how it works out. Perhaps something better will become apparent when faced with a range of concrete examples. If it works well, by all means contribute it back. As alluded to above, I'd like to go back and fill in the huge testing gap I left. I couldn't immediately see a way to test the integration easily because of the async API, but your synchronous handler might provide a way to do that.