1879106 - about:processes does not allow to kill a withCoopCoep subframe process

Status: ASSIGNED

(Toolkit :: Performance Monitoring, defect, P3)

Description

[pavel.nedr]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:123.0) Gecko/20100101 Firefox/123.0

Steps to reproduce:

1. Open https://learn.svelte.dev/tutorial/welcome-to-svelte
2. Wait some time, then open about:processes
3. Observe stackblitz.com processes
4. Try to find an information which tab is started the process
5. Try to kill the process
6. Try to copy the name of the process

The problem was discussed here: https://connect.mozilla.org/t5/ideas/identify-which-tabs-are-using-high-memory-or-cpu/idc-p/36097/highlight/true#M21033

Actual results:

1. User is not able to find which tab started the process
2. User can not kill the process (and since the tab is not known, in the situation with many opened tabs it could be very hard to find the tab which owns the process to kill both them)
3. User is prohibited from copying information from the about:processes (even with Alt or Option button pressed)

Expected results:

1. User should be able to find which tab started the process
2. User should have ability to kill the process (or, at least, to find the tab which owns it)
3. User should be able to copy data (process name, port, etc) from the about:processes

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Toolkit::Performance Monitoring' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[:Gijs (he/him)]

Thanks for this report. At a technical level, the processes in question are withCoopCoep processes. That means they fail the check here, which is why there's no [x] icon next that allows ending the process immediately. Those processes are still grouped with web ones elsewhere though. So I'm not sure if this is just an oversight in the conditional (ie I suspect there should just be an [x] next to them, like there is for normal tabs). I'm hoping Florian would know. Perhaps we can fix this condition to be an exclusion (so you don't accidentally nuke the parent or main gpu process, but we let you kill anything else at your own risk, or something).

You can also double-click items in about:processes to go to the right tab, though this doesn't appear to work for subframes. It looks like for subframes the code doesn't gather tab information. I'm not sure why. It looks like the window info included with the subframe entry in about:process's data includes an outer window ID, but I can't see any way of getting a BrowsingContext or similar from that, from JS, while in the parent process (ie a different process from the one that produced the outer window ID). I don't know why https://searchfox.org/mozilla-central/rev/a8cc31504a2379bcf8ba395d2da7bb632b5521d6/dom/chrome-webidl/ChromeUtils.webidl#802-804 uses outer window IDs rather than browsing context IDs. From a BC Id the code could pretty straightforwardly find a tab, that we could then switch to.

Although I agree that all 3 "expected results" in comment 0 would be useful, we will probably want to work on / land changes in individual bugs. But let's see what Florian says about the kill/tab issue first as that seems more critical and hopefully more straightforward than the user selection issue (which is a little tricky in terms of how the list works vs. how users expect selection to work, even if we offered some secondary UI that copied things - we'd probably want to chat to the UX team about it, whereas the other two items are straight up bugs).

Comment 4

[Florian Quèze [:florian]]

(In reply to :Gijs (he/him) from comment #3)

Thanks for this report. At a technical level, the processes in question are withCoopCoep processes. That means they fail the check here, which is why there's no [x] icon next that allows ending the process immediately. Those processes are still grouped with web ones elsewhere though. So I'm not sure if this is just an oversight in the conditional (ie I suspect there should just be an [x] next to them, like there is for normal tabs). I'm hoping Florian would know. Perhaps we can fix this condition to be an exclusion (so you don't accidentally nuke the parent or main gpu process, but we let you kill anything else at your own risk, or something).

It's likely that at the time this was developed we had a shorter list of process types, and the engineer who worked on the feature didn't have a GPU process (ie. wasn't developing on Windows). I would be tempted to allow killing all non-parent process types. Even the GPU process might make sense ot kill if it's leaking large amounts of memory; it should automatically restart within a few seconds and that might result in a more usable browser.

Comment 5

[:Gijs (he/him)]

Attachment: Bug 1879106 - allow killing non-web processes (but not the browser) from about:processes, r?florian