"Focus category" transform fails in this profile

[mstange]

Profile: https://share.firefox.dev/4a81raa

Right click any orange box, then click "Focus on category Kernel".

On the Web Console, the following error appears:
"Uncaught Error: We couldn't find a node with prefix -1 and func 1752, this shouldn't happen."

┆Issue is synchronized with this Jira Task

[canova]

Interesting, it actually doesn't fail when you click on "focus category" for the first time. When you go back and apply again, then it fails. Does that match your experience as well?

Another thing I noticed while debugging was that it was only happening if you go back with the back button. And doesn't happen when you pop the transform from the filter breadcrumbs / filter navigator bar.

I was checking the before and after call node paths here, and noticed some inconsistencies:

profiler/src/reducers/profile-view.ts

Lines 368 to 379 in 763c980

	const selectedNonInvertedCallNodePath = getFilteredPath(
	threadViewOptions.selectedNonInvertedCallNodePath
	);
	const selectedInvertedCallNodePath = getFilteredPath(
	threadViewOptions.selectedInvertedCallNodePath
	);
	const expandedNonInvertedCallNodePaths = getFilteredPathSet(
	threadViewOptions.expandedNonInvertedCallNodePaths
	);
	const expandedInvertedCallNodePaths = getFilteredPathSet(
	threadViewOptions.expandedInvertedCallNodePaths
	);

It looks like when we use the back button, the expandedNonInvertedCallNodePaths set contains the paths from the "focused" version of the call tree.

When I checked the POP_TRANSFORMS_FROM_STACK action in the reducers, there is this:

profiler/src/reducers/profile-view.ts

Lines 388 to 398 in 763c980

	case 'POP_TRANSFORMS_FROM_STACK': {
	// Simply reset the stored paths until this bug is fixed:
	// https://github.com/firefox-devtools/profiler/issues/882
	const { threadsKey } = action;
	return _updateThreadViewOptions(state, threadsKey, {
	selectedNonInvertedCallNodePath: [],
	selectedInvertedCallNodePath: [],
	expandedNonInvertedCallNodePaths: new PathSet(),
	expandedInvertedCallNodePaths: new PathSet(),
	});
	}

But when we use the back button, it goes through the UPDATE_URL_STATE action, and we don't handle that one here. We should do that. But it's a bit more difficult to determine if a back action removed a transform or not. So I think we should keep track of the committed transforms and determine if one transform is being removed.