1383978 - Update child process name on ContentChild::RecvRemoteType so about:memory process names aren't "Web Content" for webextensions process, etc.

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

I was using about:memory to figure out if I had properly turned on OOP webexts and got confused because for content processes about:memory just uses the process name retrieved via ContentChild::GetProcessName[1] and that's always set to "Web Content".

I propose we change ContentChild::RecvRemoteType to update the process name.  Once I have a bug number, I'm going to attach my prototype patch which successfully makes about:memory show "WebExtensions" for the web extensions process on linux, as well as having `pstree" also label it as WebExtensions which is also nice.

cc'ing :njn for about:memory opinions and :mstange for profiler opinions in case the profiler is somehow consuming the process name.  (I don't see calls to GetProcessName from the profiler, but it's possible it pulls the process name out of the OS process name?)

1: ContentChild::GetProcessName is either invoked in ContentChild::RecvRequestMemoryReport or nsMemoryInfoDumper.cpp's HandleReportAndFinishReportingCallbacks::Callback.  There may also be a place where "system" is used for a process name, I'm assuming that's b2g leftovers, I didn't look into it too much.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Attachment: Update child process names based on remote type

Without this patch, all remote process types share a process name of
"Web Content".  With this patch, specific names are added for "file",
"extension", and "webLargeAllocationTypes", with the default of "web"
left as the default "Web Content".

This patch also eliminates undocumented b2g-era legacy logic that had a
notion of whether it's acceptable to override the process name.  In the
b2g era, I believe processes were named based on the "app" that was
running.  It would have made sense to have the process initially named
the preallocated process, then to change the process to its app name
when specialized, trying to make it hard/impossible for the process to
rename itself so it couldn't masquerade as another app if it became
compromised.

Comment 2

[Markus Stange [:mstange]]

(In reply to Andrew Sutherland [:asuth] from comment #0)
> cc'ing :njn for about:memory opinions and :mstange for profiler opinions in
> case the profiler is somehow consuming the process name.

The profiler uses XRE_ChildProcessTypeToString(XRE_GetProcessType()) and then perf.html uses that string to massage the thread name at https://github.com/devtools-html/perf.html/blob/a880ee09a1f2ce5713a492282f907cd02241e3e0/src/profile-logic/profile-data.js#L917 .

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Comment on attachment 8889711 [details] [diff] [review]
Update child process names based on remote type

Review of attachment 8889711 [details] [diff] [review]:
-----------------------------------------------------------------

I think this should work. It will change the process name we pass to the OS, but I think that's safe to change.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1c9560f99aa0669b6a650b49af359de346b4a430
Bug 1383978 - Update child process names based on remote type. r=billm

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/1c9560f99aa0