I do not like this change so please let me know if there is a better way to read uris such as untitled or git from the main process.

I do not have a better solution right now. The window is currently still the exclusive owner of all file service registrations. This might change in the future when we enable sandbox and move file services into some backend, but this is not happening anytime soon. And even then, this backend is likely still a different process than the main process.

I glanced at the changes but I am not an expert in that code, so I trust your implementation.

Some more thoughts after gym:

• we do have the concept of asDomUri as you know which helps for remote and I wonder if this concept should be expanded so that you can always use it. the window itself would then somehow be responsible for replying to a request (not sure if https is a good idea). this would allow us to use a consistent solution for all these things where a 3rd process needs access to resources without registered file system provider
• alternatively, maybe whenever a file system provider is registered in the renderer it should also get registered in electron-main via some remote proxy? We do have a RemoteFileSystemProvider that works via IChannel (used for vscode-remote so far only)

I somehow feel that asDomUri would be the best way forward.

@bpasero Thanks for taking a look.

I'm not sure I understand the point about asDomUri. With the changes we made last month, webview resources are read from the main process using a custom protocol. I don't think we can have a custom protocol go directly to a window, so is the proposal to have a standard uri scheme for reading a resource from a specific window? For example: vscode-window://windowId?path=/path/to/resource?

I've merged this to get additional testing in insiders. We can continue iterating on finding a better solution to this

@mjbvz can you please expand on how this is currently handled in the web with service workers, would like to understand the problem model first, custom protocol are limited in capabilities, we might have to explore other options.

So on desktop, we now have this flow for loading git resources:

Webview makes resource load request
-> main process protocol handler gets request and delegates to renderer
-> renderer reads file
-> main process  gets response from renderer
-> Webview gets response from main process 

On web, we instead have the following flow:

Webview makes resource load request
-> Service worker intercepts the request and delegates to renderer
-> Renderer reads file
-> Service worker gets response from renderer
-> Webview gets response from service worker

It's the same number of hops in both cases, but the webview -> service worker communication should be pretty quick

Thanks Matt! the web solution is certainly elegant. Apart from the hops, the web solution doesn't pressure the main process since service worker gets a direct communication channel with the renderer. In desktop even if we push the logic to a background window that can establish a channel to the webview window, the custom protocol must still be handled by the main process.

Maybe we should really invest time getting service worker working for custom protocols. FWIW chrome-extension is a custom protocol for chrome browser and service worker works fine in it, so it is not impossible to get it working fine under custom protocols registered for electron, the mechanism is already there and the current blocker is electron/electron#20248 , let me look at it this week.

@mjbvz

I'm not sure I understand the point about asDomUri. With the changes we made last month, webview resources are read from the main process using a custom protocol. I don't think we can have a custom protocol go directly to a window, so is the proposal to have a standard uri scheme for reading a resource from a specific window? For example: vscode-window://windowId?path=/path/to/resource?

Yes your proposed URI is what I had in mind. As it stands, vscode-remote and e.g. git are very similar to me: only a window can (currently) resolve resources of these schemes because:

• the remote resolver is registered and known only in the window
• file system providers are only registered in the window

So having a consistent URI scheme that forwards requests to the window owning these seems elegant.

On the other hand, once sandbox for windows are enabled, the situation will likely look very different. It is possible that the window then is not the one to resolve these resources but some backend process that is privileged. Nevertheless, my point was that asDomUri could be a solution too and someone owning the window is the one that can resolve these URIs.