New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 774729 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Extensions don't share processes when over the limit in --site-per-process

Project Member Reported by creis@chromium.org, Oct 13 2017

Issue description

Chrome Version: 63.0.3239.0
OS: Win/Mac/Linux/ChromeOS

What steps will reproduce the problem?
(1) Start Chrome with --renderer-process-limit=1 --site-per-process
(2) Install two extensions with background pages.
(3) See if the extensions share a process.

What is the expected result?
The extensions should share a process.

What happens instead?
They don't share a process.

ChromeContentBrowserClientExtensionsPart::ShouldLockToOrigin returns true for extensions in --site-per-process, which enables LockToOrigin for them.  This is different than what we do normally, and it prevents process sharing because the origin lock check in RenderProcessHostImpl::IsSuitableHost comes before the extension process sharing logic.

 

Comment 1 by creis@chromium.org, Oct 14 2017

Status: WontFix (was: Assigned)
Let's fix the TODO in ChromeContentBrowserClientExtensionsPart::ShouldLockToOrigin via issue 760757 instead, so that we have a better mechanism for process sharing.  For now, let's leave extension process sharing off in --site-per-process to keep that mode more about pure isolation.

Sign in to add a comment