Best way to trigger (parts of?) content initialization in app shim processes

[Marijn Kruisselbrink]

In https://chromium-review.googlesource.com/c/chromium/src/+/7398643 I'm trying to fix an issue where in some cases an AppShim (helper process for installed Web Apps on macOS; content doesn't and shouldn't really need to know anything specific about this process type) will end up terminating itself because it receives a mojo message containing an origin with an unknown scheme. AppShim processes aren't regular child processes and as such currently don't invoke ContentMain (or much of the rest of content initialization), and as a result of that content::RegisterContentSchemes isn't called either and thus content schemes aren't registered.

This can be fixed fairly easily by adding a call to RegisterContentSchemes somewhere in early app shim startup code, as that CL does, but that requires adding RegisterContentSchemes to the public content API even though in any other case embedders would have no reason to call this method as ContentMain already does so.

Since ContentMain apparently is the public entry point to (among many other things) RegisterContentSchemes, perhaps app shims should be refactored to go through there as well? I'm not sure what all else ContentMain does (and at least some of what it does would need to be skipped/disabled since app shims need to do it slightly different), but that approach does seem to work (prototyped in https://chromium-review.googlesource.com/c/chromium/src/+/7402162, which with some minor additions to ContentMainDelegate seemingly is at least passing all our tests).

But I'm not sure what the best approach is here to address this:

- exposing and calling RegisterContentSchemes is a simple and targetted fix, and doesn't really have any risk of having unexpected side effects in app shims. But the resulting content/public API isn't great

- switching app shims to start calling ContentMain is perhaps a better long term solution, but at least I don't fully understand the consequences of that, as ContentMain seemingly does a lot of things, that might or might not all apply to app shims (and does those things before for example app shims have fully initialized base::FeatureList). As such this approach feels more risky, although it seems to work.

Any thoughts/opinions/other options I haven't thought about?

[Marijn Kruisselbrink]

Anybody have any input here? I'm leaning towards refactoring app shim processes to invoke ContentMain (and the few extra hooks added to ContentMainDelegate that that requires), but I'm still not entirely sure if that is really the best way forward, and if the possible extra requirements that could place on ContentMain are worth it (mainly that base::Feature state isn't and can't be fully initialized at that point in time).

[Charlie Reis]

Thanks for asking about it.  I'm also not that familiar with what is done in ContentMain, but I agree with your preference to make app shims go through ContentMain (with customizations) rather than exposing just the part you need.  In the long term, that seems like it will make app shims behave more consistently with the rest of the browser, where the only differences are what's necessary for app shims.  In the other approach, anything new added to ContentMain would be missing from app shims until we notice it's a problem.  Since my (uninformed) guess is that most of ContentMain is probably relevant, I'd also lean towards what you're suggesting.

Happy to hear opinions from other content owners if they know more about what's in there!

Charlie

--
You received this message because you are subscribed to the Google Groups "content-owners" group.
To unsubscribe from this group and stop receiving emails from it, send an email to content-owner...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/content-owners/CA%2BOSsVbDnXHNCZ8-T4J5%3DjEcWnyTOcU_yUB7MGAsKD_%3D6zxGYA%40mail.gmail.com.