Closed
Bug 1385615
Opened 7 years ago
Closed 6 years ago
about:support shows bogus values for "Web Content Processes"
Categories
(Core :: DOM: Content Processes, enhancement, P3)
Core
DOM: Content Processes
Tracking
()
RESOLVED
DUPLICATE
of bug 1505322
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox-esr60 | --- | wontfix |
firefox54 | --- | unaffected |
firefox55 | --- | wontfix |
firefox56 | --- | wontfix |
firefox63 | --- | wontfix |
firefox64 | --- | wontfix |
firefox65 | --- | wontfix |
firefox68 | --- | fixed |
People
(Reporter: aswan, Unassigned)
Details
The "Web Content Processes" row in about:support shows a value of X/Y where X is the total number of content processes (counting web as well as file, extension, and largeAllocation). But the value of Y comes (in a roundabout way) form the dom.ipc.processCount preference which only counts web content processes. A number of people have reported seeing values like "5/4" in that row which is of course very confusing.
Ideally we would show separate rows for each content process remoteType (the name of the row and the original bug 1381175 seem to agree with this). In the shorter term, only counting web content processes toward X would be a good start.
Comment 1•7 years ago
|
||
If the patch is simple, this could be a good dot release ride-along candidate too.
status-firefox54:
--- → unaffected
status-firefox55:
--- → fix-optional
status-firefox56:
--- → affected
status-firefox-esr52:
--- → unaffected
Comment 2•7 years ago
|
||
I don't know of a simple way to iterate through processes, that also provides their remote type. This counter just comes from `Services.ppmm.childCount`.
Comment 3•7 years ago
|
||
Also, it's "technically" correct to show "5/4" for the file:// URL case.. because it is basically a content process that ignores the upper bound for child processes and always create a new process.
The case is stronger for not counting the webextension process (in my mind).
But yeah, I agree that the best solution would be rows for each remote type. Or maybe an entire new section, that would also bring info about the large-allocations process, gfx process, plugin process, etc. (but I know that this is not the bug for it.. just putting it out there what I've thought about this)
Comment 4•7 years ago
|
||
You can all `ContentParent::GetAll()` like this:
http://searchfox.org/mozilla-central/source/dom/workers/ServiceWorkerManagerService.cpp#115
And then call `actor->GetRemoteType()` on each one returned. For example, see the patch in bug 1383905.
Updated•7 years ago
|
Component: General → DOM: Content Processes
Product: Firefox → Core
Updated•7 years ago
|
Priority: -- → P3
Comment 5•6 years ago
|
||
This issue is still reproducible on the following builds: Fx 65.0a1, Fx 64.0b10, Fx 63.0 and Fx 60.3.0esr.
status-firefox63:
--- → affected
status-firefox64:
--- → affected
status-firefox65:
--- → affected
status-firefox-esr60:
--- → affected
OS: Unspecified → All
Hardware: Unspecified → All
Version: unspecified → Trunk
Updated•6 years ago
|
QA Contact: cristian.comorasu
Comment 6•6 years ago
|
||
(In reply to Ben Kelly [:bkelly, not reviewing] from comment #4)
> You can all `ContentParent::GetAll()` like this:
>
> http://searchfox.org/mozilla-central/source/dom/workers/
> ServiceWorkerManagerService.cpp#115
>
> And then call `actor->GetRemoteType()` on each one returned. For example,
> see the patch in bug 1383905.
Is there a JS equivalent for this?
Flags: needinfo?(mrbkap)
Comment 7•6 years ago
|
||
(In reply to :Gijs (he/him) from comment #6)
> Is there a JS equivalent for this?
I don't think so, but there's `nsIContentProcessInfo` defined in [1] that could be extended to include a `remoteType` property. We'd also need a JS API to get the list of live content processes, though. I'm not sure where the most natural place for that to live would be, but it should be easy to add.
[1] https://searchfox.org/mozilla-central/rev/b03a62c3c82316e733a3b09622c1cb7e59f64cc3/dom/interfaces/base/nsIContentProcess.idl#10
Flags: needinfo?(mrbkap)
Comment 8•6 years ago
|
||
This information is now accessible in JS through Services.ppmm.getChildAt(i).remoteType.
Duplicating this bug forward as I have already posted patches on the other one
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Updated•5 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•