firefox-devtools / firefox-devtools/profiler
Visual metric markers are added to the incorrect tab main thread
- Dominant language
- TypeScript
- Stars
- 1.5k
- Forks
- 491
- Avg merge
- 3d 5h
- Merged PRs (30d)
- 30
Description
While we are processing the profile we also process the visual progress data and add markers for them to 2 threads:
1. Parent process main thread
2. 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](https://mozilla-hub.atlassian.net/browse/FP-910)
Contributor guide
Research direction
Start in src/profile-logic/process-profile.js around lines 1958-2163, especially the visual progress marker handling and RefreshDriverTick heuristic. Reproduce the incorrect selection with the linked profile, then determine whether the immediate marker-count approach or selector-based activity-score approach is intended. Done means visual metric markers are assigned to the correct tab main thread.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100