[Problem/Bug]: Installing Webview2.tlb along with the application

[akguptakgp]

What happened?

I have chromium sandbox type architecture where my main process runs with reduced rights. To support webview2 in that setup, I am using com pointer sharing across process and creating the webview2 object using the helper process which is running with full rights. The problem is that webview2 com pointer sharing across process requires typelib registered with the system. I also tried using the tlb provided with the nuget package but that was not compatible with my use case as it didn't allow pointer sharing across process, so I use the following approach to generate the new tlb from the webview2 idl file provided with the nuget package.

1. typedef the HWND param used in interface calls to LONG_PTR as this is not automation compatible.
2. Add dual attribute to all the interfaces to make them automation compatible.

With these changes, I was able to share the webview com ptr across process. my question is can we follow this approach and register the generated tlb with the system using my installer? OR do you foresee any problem in this approach?

Importance

Blocking. My app's basic functions are not working due to this issue.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

latest

SDK Version

2.1.0.2210.55

Framework

Win32

Operating System

Windows 11

OS Version

22631.3155

Repro steps

NA as the issue is a development query only.

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

No, this never worked

Last working version (if regression)

No response

[victorhuangwq]

@LiangTheDev could you help take a look at this question?

[akguptakgp]

@LiangTheDev can you please help answer this question?

[LiangTheDev]

We never tested what you are doing and WebView2 is not designed to be a real COM object that could be marshaled to different process. We even requires all interaction with the WebView2 happens on the same thread.

WebView2 running at full trust is less ideal when the app itself runs in a sandbox. Is it possible to run the app in normal UWP app container sandbox? WebView2 can run in app container.

[akguptakgp]

Thanks @LiangTheDev for the response.
My app has more restrictions than normal UWP app container such as job object restrictions, alternate desktop and other OS process mitigations. Due to all these restrictions, it was not working when invoked directly.

However, regarding your concern "We even requires all interaction with the WebView2 happens on the same thread" - Yes, from a webview2 perspective it would run in the same thread only. The other process creates a wrapper class exactly same as the original webview2 interfaces and proxies all the call to webview2. I tested this approach, and it works without any issues. My main concern is regarding installing tlb with the application. Can that cause issues for the other apps. Ideally that should not be the case because none of the app would share webview2 interfaces across boundary and even if they do this should be helpful only.

[LiangTheDev]

It seems to me that you are building communication mechanism between the sandboxed process and a medium IL process, and WebView2 interaction happens to be needed in this IPC. If we don't trust the sandboxed process, do we want to directly expose all WebView2 APIs to the sandboxed app, or it is better to build a wrapper of the WebView object with limited interaction to WebView2 so that the sandboxed app could not have too much control to the medium IL WebView browser process?

By defining a separate wrapper, you would also not impact other apps by accident. No other apps should be using WebView2 API as real COM object or trying to use WebView2 API from different threads/processes. However, if proxy is defined, the behavior of these potentially usage would change from simple failure to unexpected cross thread/process calls that might cause deadlock or wrong object access sequence and very hard to debug.

So, I would recommend building an app specific wrapper for accessing webview from the sandboxed process, or turn the design around and make the process owning WebView2 the "main" process and run dangerous part of the app in the sandboxed app with some COM limited interface to interact with the sandbox process.