1583362 - Audit component manifests and restrict processes where they may load to avoid surprises

Status: NEW

(Firefox :: General, task, P3)

Description

[Mike Conley (:mconley) (:⚙️)]

These components are being loaded, it seems, in both the parent and content processes. I can't think of a good reason why these should be in content processes. In fact, I'm reasonably certain none of those components expect to be run in a content process.

We can declare a restriction on which process these can open in like this.

We might want to go through all of the other components.conf files out there and ensure that they're being loaded in the smallest set of process types. This could be low-hanging fruit for MemShrinking content processes.

Comment 1

[Kris Maglione [:kmag]]

How are they being loaded? I'm not aware of any code that would cause them to be.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Ack, you're right - I misread StaticComponents.cpp and thought this set were being loaded eagerly on start-up en-masse. Looks like they're loaded on-demand.

Still, we probably don't want these to ever load in the content process.

Comment 3

[Kris Maglione [:kmag]]

It's true, it's probably always a good idea to add a process restrictions to components that we never expect to load in a child process.

Comment 4

[:Gijs (he/him)]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #0)

We might want to go through all of the other components.conf files out there and ensure that they're being loaded in the smallest set of process types. This could be low-hanging fruit for MemShrinking content processes.

Broadening summary a bit. This seems like a P3 for now, lemme know if you think it needs prioritizing more urgently...