The profiler front-end gets confused about the profile start time in some profiles

[fqueze]

It looks like the profiler gets confused about the start time of the profiler in profiles like this: https://share.firefox.dev/3IfJd6Z (this is using the 'power' preset I'm thinking of adding in https://bugzilla.mozilla.org/show_bug.cgi?id=1778282)

My guess is that it gets confused by the use of the "Markers - All Threads" feature, but I'm not sure. The part I really don't understand is how it decides how long the entire range is. Here are 3 profiles captured consecutively without touching the settings: https://share.firefox.dev/3Ik5RLj (range is wrong by about 8ms) https://share.firefox.dev/3yKwkP7 (range is wrong by 1.5s) https://share.firefox.dev/3RdVPzC (range is wrong by 420s)

[julienw]

The part I really don't understand is how it decides how long the entire range is.

When there's no sample in a thread, we decide the range by looking at markers for this thread. See https://github.com/firefox-devtools/profiler/blob/7bb5fb80f4abc50ac9590d344052a5ab8e3be4a4/src/profile-logic/profile-data.js#L815. Looks like some threads in these profiles are in this situation.

For example for the third Profile: https://share.firefox.dev/3NFS2Ig

Maybe we could make the logic a bit different, that if one thread at least have samples, we shouldn't look at markers in any thread. Or find out if one thread is an outlier compared to all other threads, and ignore it if necessary.

[fqueze]

https://phabricator.services.mozilla.com/D151127 will hide the issue again by removing the primary source of long markers starting before the profiler.