BTW, what's your plan with --process-per-tab? Do you plan to keep the current support in the future (related to site isolation project)?

In general, we expect Site Isolation will be configurable by embedders.

The actual --process-per-tab flag may not be the best thing to keep long term, but I understand that there are use cases that want to avoid process swaps on cross-site navigations (at least when there aren't privilege level differences, like WebUI).  Without designing something on the spot, maybe there will be a way for embedders to tell content/ not to swap processes for cross-site navigations, without using this particular tab.  Would that be sufficient for what you need?

Anyway, I'll try to find time to investigate this issue to see how we can fix it in the meantime.

Sorry for late reply. I missed your post entirely.

Our use case is essentially to restrict resources on embedded devices in different ways. We have found that we generally use less resources (mainly memory) with the process-per-tab configuration.
We have some features that put multiple tabs into the same renderer process which seems to be problematic with your suggestion as I understand it. 

As an embedder the ultimate interface would be something that would allow us to make platform decisions regarding process creation that potentially override decision in chromium, giving us full control. :)

Putting multiple tabs into the same renderer process sounds independent of --process-per-tab, right?

If that's your goal, you could try something like --renderer-process-limit=1, which will only create new processes when required for security (e.g., WebUI).

Maybe we can find ways to offer a bit more control to embedders than we do now, but I'm not sure how much we can commit to supporting that.

> Putting multiple tabs into the same renderer process sounds independent of --process-per-tab, right?

Currently it breaks since --process-per-tab is not honored like it used to be. But that might be related to that our implementation is somehow depending on it while it shouldn't. I think we just reuse the content::SiteInstance when creating new WebContents (disclaimer: might be some more details or local patches that I am not aware of).

 --renderer-process-limit=1 sounds interesting in this case. Would that override the process model, disabling site isolation except for security?

> Maybe we can find ways to offer a bit more control to embedders than we do now, but I'm not sure how much we can commit to supporting that.

I think the SiteIsolationPolicy::AreCrossProcessFramesPossible interface kind of works for what we need but I understand you want to get rid of it?

Yes, --renderer-process-limit=1 means there will only be one renderer process unless IsSuitableHost says no for a given URL, which I think should only happen for WebUI by default.  In Chrome, it will also happen for things like extensions, the Chrome Web Store, etc, but not for normal cross-site navigations.  I would suggest trying that out.

AreCrossProcessFramesPossible is probably not what you want.  That's not something that embedders control, but rather a reflection of whether some policy might create OOPIFs.  And yes, we'll be removing it shortly, since all code in content/ should be able to handle OOPIFs, whether or not a policy decides to create them.

There was some discussion of this in https://codereview.chromium.org/2964033002/, which landed in r485292.  I tried to address --process-per-tab in that CL as well, but that was blocked by some layout tests that assumed --isolate-extensions took precedence.

Alex and I seem to be leaning towards a new --process-per-tab mode that disables unnecessary process swaps for cross-site navigations, but defers to other security modes that the embedder has configured which might require process swaps (e.g., --isolate-extensions, --isolate-origins, etc).  If the embedder doesn't configure any of these, --process-per-tab would work the same as before.

Sorry for the late reply (back from vacation yesterday). This sounds like it would work for what we need. Thanks for considering our use case.

I'm also having trouble with this and I wonder if a workaround would be to replace every navigation in my code with code that runs a script that sets the `location.href` to the URL I want to navigate to. I've tested it and so far it didn't swap the render process.

@cries: What's the status of the --process-per-tab mode you depicted in comment 7? Has that been implemented?

Comment 10: Sorry, no, our hands have been full with the accelerated efforts to launch --site-per-process.