Enable COI for desktop with credentialless

[jrieken]

For desktop we can enable COI with COEP: credentialless. That's possible because chromium supports this new/proposed header value which relaxed loading cross-origin resources lacking the CORP header.

[jrieken]

Reverted, reopened because this has very likely caused #187030

[jrieken]

Enabling COI caused a perf regression (#187030) and therefore we are holding back. @deepak1556 Any idea why enabling COI would cause this?

[deepak1556]

Looked into this today and I have an answer for the slowdown,

In all cases, the first navigation to an origin happens from about:blank. So chromium creates a render process for the null origin and if the destination origin in our case vscode-file://vscode-app can commit in this process (always the case for first navigation) then the process will be reused without any browserinstance swap. This is what we see when coi is disabled,

BrowserInstance Swap result with COI disabled:

Process list result with COI disabled:

When coi is enabled on an origin, chromium has logic (added in https://chromium-review.googlesource.com/c/chromium/src/+/3945190) to always force swap the browserinstance which leads to creation of new render process. This seems to apply to even when navigating from the null origin. Following screenshots show that there is a force swap on the browserinstance and there are two renderer process, pid 17824 from the null origin and pid 14756 for the vscode-file://vscode-app origin.

BrowserInstance Swap result with COI enabled:

Process list result with COI enabled:

RenderFrameHostImpl::DidCommitProvisionalLoad for COI enabled

It looks like the site instances now have a new lock attribute called process_lock which is {} for normal navigations, but ends up being { vscode-file://vscode-app/ cross-origin-isolated coi-origin='vscode-file://vscode-app' } in the case of coi origin, so a coi origin does not get committed to a process that previously loaded a non coi origin.

tl:dr; there is a restart of the render process when coi is enabled and this is a penalty we will have to pay with coi origins for the initial navigation. Maybe chromium can adjust if first navigation on the app launch is to a coi origin then the process lock on null origin can be retagged and reused ? This needs discussion in upstream.

[deepak1556]

Upstream issue filed as next step https://issues.chromium.org/issues/375314974

[DanTup]

@deepak1556 is this enabled now? I'm seeing wasm load in some Dart DevTools views where it didn't before (which I believe was because of no COI) and #231665 looks like it enables this, but since this issue is still open and you linked a new Chromium issue that says "we are looking to enable coi", it's not clear to me what the current status is expected to be.

[deepak1556]

Hi @DanTup , nope it is not enabled yet (it was reverted in #231899). The chromium issue to improve startup performance needs to be resolved first before we can adopt COI again. Upstream is working on it.

[eyebrowsoffire]

I mentioned this in the other bug, but this is because on the flutter engine side we added a single-threaded version of the wasm build that works in a non-COI context.