Either allow, or actively prevent changing site-per-process mode midflight |
|
Issue descriptionChanging site-per-process mode midflight can lead to various correctness issues (e.g. same-origin frames being put into different processes), unless one is very careful (e.g. closes all the WebContents before changing the site-per-process setting). This becomes a potential problem, after moving the kSitePerProcess feature to the //chrome layer and letting //content embedders return the desired setting via ContentBrowserClient::ShouldEnableStrictSiteIsolation. We should either: 1. Allow turning kSitePerProcess mode on-or-off midflight (with safety checks?) or 2. Make it impossible to change the kSitePerProcess mode midflights (e.g. by memoizing the value within SiteIsolationPolicy::UseDedicatedProcessesForAllSites().
,
Mar 23 2018
Just for reference, the CL that adds ShouldEnableStrictSiteIsolation() and where this came up is https://crrev.com/c/976880. There are indeed problems with changing this dynamically at runtime: another example is that LockToOriginIfNeeded checks correctness of origin locks, and those will probably lead to CHECKs if the value of site-per-process is flipped at runtime. But I can also see some potentially valid, sufficiently restricted use cases of this. E.g., enabling site-per-process only for particular profiles. |
|
►
Sign in to add a comment |
|
Comment 1 by lukasza@chromium.org
, Mar 23 2018