Heads-up: short --site-per-process trial on Canary (Win, Mac, Linux, CrOS) starting next Monday

[Łukasz Anforowicz]

Hello!

The Site Isolation team is planning a week-long Canary experiment of the full --site-per-process isolation policy (https://crbug.com/760778).  This policy gives a dedicated renderer process to every web site, using out-of-process iframes for all cross-site iframes.  This version of the policy is likely to increase resource usage too much to be viable to launch to Chrome Stable, but running an experiment will give us concrete data about the impact on process count and memory usage.  This will help guide us towards a more practical policy which isolates a subset of sites, and will inform us more about the relation between process count, resource usage, and responsiveness.

The experiment will be limited to Windows, Mac, Linux, and ChromeOS platforms.  We plan to run the experiment for ~1 week - from Monday Oct 16th to Monday Oct 23rd.  Experiment groups: Enabled_SitePerProcess_25_20171016 (this is the new experiment), Enabled_SignInIsolation_25_20171016 (has been enabled on Canary since Aug 14th), Control_25_20171016.  We’ve created a doc where we have more details about the experiment and where we plan to track the experiment’s progress: go/site-per-process-experiments.

We think that all the known OOPIF crashes are fixed and that the remaining OOPIF support issues should not block the Canary trial.  In fact, some of us have been running Chrome with chrome://flags/#enable-site-per-process enabled for quite a while without encountering any major issues.  FWIW, go/site-per-process-experiments includes a link to a public list of known functional issues - the only major gap we are aware of is printing of OOPIFs (we plan to work around the NTP issues before the trial starts).  Please shout if you think we might have missed a trial blocker, or if you’d like us to reconsider the dates of the trial.  Please also share any additional metrics that you think we should be paying attention to (and which aren’t already captured by go/site-per-process-experiments).

If issues are discovered as a result of the trial, please don’t hesitate to reach out to us (adding a Internals>Sandbox>SiteIsolation component to a Monorail bug is probably the easiest way to do it).

Best regards,

Lukasz (on behalf of the Site Isolation team)

[PhistucK]

The Developer Tools known issue (the Network panel one) can be quite harmful and since web developers are advised to use the canary, I think it is a bit unfair to break their debugging experience with this known issue.

☆PhistucK

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/c5cd46d8-0f4f-477f-a9c1-67994a1957b9%40chromium.org.

[Charlie Reis]

Thanks for the concern-- we'll check in on the status of that bug.  However, since the trial only affects 25% of Canary channel for a week and the bug itself only affects the ability to inspect network requests made from cross-site iframes within the trial, I don't think it's likely to be a blocker for the trial.

Charlie

[PhistucK]

I just think it might seem a little ungrateful since you specifically ask web developers to use it and report issues.

While it is helping them (report bugs early, but work with an unstable browser) helping you (fix bugs early) helping them (their sites do not experience those bugs in the stable channel), knowingly breaking their debugging experience is a little gross (especially since they are not aware of it, because no one subscribes to chromium-dev or read anything too Chromium-internal since they were instructed to use the canary by web development advocates, nor should they).

☆PhistucK

[Ryan Sleevi]

Hi Phistuck,

While I agree with your general concerns, I'm wondering whether or not you think the ability for such developers (using Canary) to set explicit field trials (to opt-in or opt-out) is a sufficient mitigation?

That is, any experiment has the potential of (unintentionally) breaking the debugging experience, and such command-line options offer a way to resolve such breakages, independent of either a binary release, bug fix, or field trial configuration change. Here, we at least seem to know there may be some breakage, and so a PSA is being given to help highlight that. This seems to be a good balance - between the need for real data and insight and the need to support developers debugging - so I'm curious whether or not the ability to opt-out is being considered in your concern.

Certainly, for the developers who are running Canary (to detect issues, as you note), and aren't following chromium-dev (and thus don't see the PSA), it seems like the reasonable next step would be that they would file bugs, right? As that is why they'd be running Canary - to detect if Chrome has bugs? Breaking the developer experience would, for these users, be seen as a bug - and so, if they file a bug, they could be linked to this thread or to instructions on how to opt-out temporarily - and that would also resolve their experience.

Does that sound correct?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CABc02_K%2BJB6QgyC6zp5PKZMNF7X2Lke9m3L%2ByTSM6603nVi9tQ%40mail.gmail.com.

[PhistucK]

Yes, it is correct, but this is still intentionally wasting their time.

If you can arrange for a small note/message ("Requests from frames might not show up due to a field trial, more information at (this thread).", or maybe also, "chrome:net-internals can be used for those, though verbose") to show up in the network panel, during that week/when that field trial is turned on, that would certainly be enough and mitigate all of my concerns.

(As it stands, unless I am missing it, this thread currently does not contain a one line command or other clear instructions for disabling this specific field trial)

☆PhistucK

[Łukasz Anforowicz]

On Saturday, October 14, 2017 at 12:36:29 AM UTC-7, PhistucK wrote:

Yes, it is correct, but this is still intentionally wasting their time.

If you can arrange for a small note/message ("Requests from frames might not show up due to a field trial, more information at (this thread).", or maybe also, "chrome:net-internals can be used for those, though verbose") to show up in the network panel, during that week/when that field trial is turned on, that would certainly be enough and mitigate all of my concerns.

(As it stands, unless I am missing it, this thread currently does not contain a one line command or other clear instructions for disabling this specific field trial)

 

Good point - I should have included the instructions in the original email:

• To opt out of the experiment: Start Chrome with the following cmdline flag: --disable-features=site-per-process
  
• To force into the experiment: Start Chrome with the following cmdline flag: --enable-features=site-per-process
  
• To verify if OOPIFs are present: Visit https://csreis.github.io/tests/cross-site-iframe-simple.html and see if there's a subframe process for it in Chrome's Task Manager. 

[Łukasz Anforowicz]

On Saturday, October 14, 2017 at 12:36:29 AM UTC-7, PhistucK wrote:

Yes, it is correct, but this is still intentionally wasting their time.

If you can arrange for a small note/message ("Requests from frames might not show up due to a field trial, more information at (this thread).", or maybe also, "chrome:net-internals can be used for those, though verbose") to show up in the network panel, during that week/when that field trial is turned on, that would certainly be enough and mitigate all of my concerns.

Thanks for the suggestion - let's follow-up on that at https://crbug.com/750901 and https://chromium-review.googlesource.com/c/chromium/src/+/721599.