Some hidden tracks reappear after sanitization

[julienw]

STR:

1. Open a profile with memory or network tracks, for example https://share.firefox.dev/3nQF5zG
2. Hide the memory or network track, as well as a process thread track. In the previous link this is already done (you can double-check with the "hidden tracks" button)
3. Publish, take care that "Include hidden tracks" is unchecked.

=> The Network or memory tracks reappear.

┆Issue is synchronized with this Jira Task

[julienw]

Note that don't remove the network and memory tracks from the profile when we sanitize it. I believe that we assume we removed all hidden tracks and just reset that state, but instead we should keep the hidden track information for the ones we don't remove.

This happens here: https://github.com/firefox-devtools/profiler/blob/0ecc660cb4fc6877dff6cb8db08d08451453ff36/src/reducers/url-state.js#L334-L337 and in https://github.com/firefox-devtools/profiler/blob/0ecc660cb4fc6877dff6cb8db08d08451453ff36/src/reducers/url-state.js#L370-L375

I think instead we should remove from the Set and the Map (respectively) only thread-related tracks. (as opposed to memory, network, that are tracks that aren't threads).

This will need some research around what a TrackReference is, etc.

[julienw]

hey @Somaru-chan, do you want to look at this one?

[Somaru-chan]

hey @Somaru-chan, do you want to look at this one?

Sure. I'm passionate about learning new topics, but I think I will need some guidance on this one. Would that be ok?

[julienw]

Start by trying the scenario as outlined in the initial description. Then you should read up a bit about redux, because this is clearly a redux-oriented issue. To see exactly what actions are sent and how the state looks like, you can look at the webconsole when running the project with your development server. Then you can inspect what this action looks like, and what the state looks like. Lastly I also suggest that you use a debugger, or add console statements to the code, to better understand what's going on in this code. I'm sure you can do it :-)

[Somaru-chan]

@julienw Thanks a lot for explaining the steps. I've looked over the code and was able to tell that thread-based tracks could be told apart from network and memory tracks using localTrack.type. But I'm having a bit of trouble connecting the dots here, since from my understanding the current to-do list is:

• 1. Keep the information for the hidden tracks that are not removed when sanitizing.
• 2. Remove from Set() only thread-related tracks.
• 3. Remove from Map() only thread-related tracks.

Not sure if achieving steps 2 and 3 will accomplish 1. I guess what I'm really asking is, how to know which files need modification in order to achieve the above?

[julienw]

Yes, 2 and 3 will accomplish 1.

[julienw]

hey @Somaru-chan, do you still intend to look at this more? It's totally OK if you don't, but please tell us so that we can update the status of this bug and somebody can take it :-) Thanks!

[Somaru-chan]

hey @Somaru-chan, do you still intend to look at this more? It's totally OK if you don't, but please tell us so that we can update the status of this bug and somebody can take it :-) Thanks!

Hi @julienw. Please forgive the late reply, this past month has been challenging due to having to move from a country to another. Though I am grateful for the opportunity, I don't believe it'll be within my capacity to work on this issue at the moment. Thank you for your help & patience, and I hope to make more contributions in the near future :)

[julienw]

no worries, thanks for your reply!