Fix the compare view when using the same profile in both entries

[julienw]

I use this often to test the compare view, because it's easier. So I'd like this edge case to work.

[codecov]

Codecov Report

Attention: Patch coverage is 50.00000% with 1 line in your changes missing coverage. Please review.

Project coverage is 86.03%. Comparing base (ea9787b) to head (63fbde3).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
src/profile-logic/merge-compare.js	50.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #5469 +/- ##
==========================================
- Coverage 86.04% 86.03% -0.01% 
==========================================
Files 312 312 Lines 30356 30358 +2 Branches 8294 8295 +1 ==========================================
+ Hits 26119 26120 +1 - Misses 3642 3643 +1 
Partials 595 595 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[canova]

It looks good to me overall, but I'm surprised to see how it can cause an issue in the comparison view. Don't we usually use the committed range for the compare profiles? Which part fails when we have these values?

[julienw]

The compare function adjusts all timestamps so that the start of the profile is effectively "0". All samples and markers have now a value that is relative to "0". But without this patch we were copying the existing value for these meta properties.

Then we use this information from the meta object when it's present in

profiler/src/profile-logic/profile-data.js

Lines 1288 to 1300 in 55d6087

	export function getTimeRangeIncludingAllThreads(
	profile: Profile
	): StartEndRange {
	constcompleteRange={start: Infinity,end: -Infinity};
	if(
	profile.meta.profilingStartTime!==undefined&&
	profile.meta.profilingEndTime
	){
	return{
	start: profile.meta.profilingStartTime,
	end: profile.meta.profilingEndTime,
	};
	}

instead of computing the range from the threads data.

And that's where it breaks!