Link to about:processes requirements doc:

https://docs.google.com/document/d/1gwzH2T0lI_Rrt2XzH0kBQ42juG3H7jFwN3j6xJD82RM/edit

The requestProcInfo call seems to be exactly what we need (thanks @tarek!) – it collects info on processes and threads without waking them up, which is great.

A few UX requirements:

• we'll have hundreds of processes;
• each process will have dozens if not hundreds of threads (not sure whether we'll show threads of all processes at once);
• everything will be updated once every few seconds;
• for each item, we'll have at least 5 pieces of info (tab name, either URL or <title>, pid, CPU usage and memory usage);
• in future versions, we'll have additional data;
• we'll want the ability to order at least by tab name, by CPU usage and by memory usage and keep it ordered;
• we want to avoid saturating the parent process with this display.

So, I haven't been following our big xul/xbl replacement, but I wonder what's the best component to represent processes/threads here. Also, can we get the content of an about: page to be displayed in a content process rather than in the parent process?

Any ideas, Gijs, Florian?

The current about:performance is displayed using just HTML/CSS/JS, so you might want to fork it. It seems to be doing OK with hundreads of tabs.
A xul:tree would be more efficient, but I wasn't (and still am not) clear on whether the xul tree implementation would remain, or was planned for removal.

I think displaying an about: page in a content process is possible (https://searchfox.org/mozilla-central/rev/a4d62e09a4c46aef918667fa759bf9ae898dc258/netwerk/protocol/about/nsIAboutModule.idl#53-61).

(In reply to David Teller [:Yoric] (please use "needinfo") from comment #2)

So, I haven't been following our big xul/xbl replacement, but I wonder what's the best component to represent processes/threads here.

I don't think we have a good answer here. The answer used to be <tree>, I think we're trying to avoid adding new consumers of that UI. Other places use <richlistbox> (like the prefs) but they perform poorly with many entries (cf. bug 1629366), or tables/HTML (like about:config), which seem to perform slightly better but still not great.

Also, can we get the content of an about: page to be displayed in a content process rather than in the parent process?

Yes, but you should use the privileged about process because you're passing privileged information that normal content processes should ideally not have access to, and handing it to any old content process would be a security risk. See the registration of about:logins for an example.

Well, I guess I'm going to prototype this with <table>.

about:processes is already in place and we don't need to track this meta for Fission milestone for the remaining work.

Florian, please triage this list of remaining work for about:processes and prioritize as you see best. Thanks!

Many thanks to everybody involved in making "about:processes" happen. I have been waiting for something like this ever since multi-process was introduced a few years ago. There are situations where it is really useful to be able to see which process is doing what. Again, many thanks!

(In reply to Neha Kochar [:neha] from comment #7)

Florian, please triage this list of remaining work for about:processes and prioritize as you see best. Thanks!

With bug 1777563 fixed, I think we can now close this bug, even if some dependencies are still open.