Visual metric markers are added to the incorrect tab main thread
While we are processing the profile we also process the visual progress data and add markers for them to 2 threads:
- Parent process main thread
- Content process main thread
This happens here: https://github.com/firefox-devtools/profiler/blob/1a1dc6012054cfef0b26982dd65379e73d3311b1/src/profile-logic/process-profile.js#L1963
It's easy to find 1, but it's trickier to find 2. It's possible to find incorrect content processes because we don't know which test is running which website at a point. So we have this (not properly working) heuristics: https://github.com/firefox-devtools/profiler/blob/1a1dc6012054cfef0b26982dd65379e73d3311b1/src/profile-logic/process-profile.js#L1978 https://github.com/firefox-devtools/profiler/blob/1a1dc6012054cfef0b26982dd65379e73d3311b1/src/profile-logic/process-profile.js#L1958-L2163
But like I said, it's not working well. For example, in this profile, it found a random web content instead of the correct one: https://share.firefox.dev/4jxRNPl
I think there are a few things we can do.
Easier and more immediate fix:
Currently we are returning if a thread that contains a RefreshDriverTick marker is found. We can change that to return the thread that has the most RefreshDriverTick markers.
A more complete fix:
Currently this happens in profile processing. That's why we have limited information about the thread as long as we don't compute it there. I think it would be better to move this processing into selectors instead. Then we can get an access to the thread activity scores and put these markers to the tab process with the highest activity.
┆Issue is synchronized with this Jira Task