OOPIF support for //headless |
||||
Issue descriptionsite-per-process has shipped to desktop platforms in M67/Stable. Let's use this bug to track adding OOPIFs support to //headless, so that it may also start using site-per-process (and so the tests based on //headless test the mode that Chrome actually ships to end users). Right now there are 2 known issues that break OOPIF support in //headless, but there may be more hidden bugs lurking under the surface. The 2 known issues are: - Issue 715924: HeadlessWebContentsImpl incorrectly assumes there is only one renderer per tab - Issue 788850: OOPIF support for virtual time in headless mode Note that in issue 856734 we plan to make site-per-process (and therefore presence of OOPIFs) the default at the //content layer (at least for desktop platforms). Initially we will opt-out //headless via headless/lib/browser/headless_content_browser_client.h. ⛆ |
|
|
,
Aug 9
To take it further, all the existing production scenarios for headless are around automation and we actively don't want site isolation / oopifs there. In fact, we'd like the opposite such as enforcing fine-grained control over renderers for site so that we could manage and run arbitrary sites in given renderers.
,
Aug 10
RE: #c2: all the existing production scenarios for headless are around automation and [therefore] we actively don't want site isolation / oopifs there I don't think I follow :-( 1. Even after all the OOPIF bugs are fixed, there will still be scenarios where website's behavior may differ with and without OOPIFs (e.g. see the race between postMessage and layoutissue in issue 828529 and the explanation in https://developers.google.com/web/updates/2018/07/site-isolation#full-page_layout_is_no_longer_synchronous). 2. If there is a risk that the website behavior differs with and without OOPIFs, then I assume we want the automation scenarios (production and test) to behave in a way compatible with the product that we ship (i.e. with Chrome). 1 + 2 would imply to me the we *do* want site isolation in //headless... Otherwise //headless might give back different results (e.g. screenshot results) than Chrome would.
,
Aug 10
BTW: I also assume that security benefits of Site Isolation are also relevant for at least _some_ automation scenarios. I can see that credentials/secrets worth protecting against cross-origin access may be more rare in automation scenarios, but I assume they still exist (e.g. I assume that it is theoretically possible to run a //headless browser with the same user profile directory as the one used by the real Chrome browser). |
|
►
Sign in to add a comment |
||||
Comment 1 by dgozman@chromium.org
, Aug 9