User Agent: Mozilla/5.0 (Windows NT 6.3; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

Using the Firefox Profiler, capture a Profile. While looking at the resulting Profile, click "Profile Info" towards the top-right of the window. Observe the timestamp indicated by "Recording started".

Actual results:

Profiler "Profile Info" item "Recording started" shows the time the entire Firefox browser was started.

Expected results:

Profiler "Profile Info" item "Recording started" should show the time the currently displayed Profiler recording was started.

The Bugbug bot thinks this bug should belong to the 'Toolkit::Startup and Profile System' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Thank you Bob for the report.

This information is recorded in the Gecko Profiler. To be investigated...

This is actually a miscommunication between the backend (Gecko Profiler inside Firefox) and the frontend (profiler.firefox.com)!

Looking at the code, in the JSON output, meta.startTime is actually the process start time.
But in the frontend, this value is presented as "Recording started".

So from there, I think:

• We should immediately rename the frontend field to indicate that this is the process start time. I've filed an issue on Github for that. This will fix all profiles past, present, and future, because that's what's always been recorded, and I don't think we should change the meaning of this JSON field.

• The frontend already computes the earliest time, in order to display the appropriate time range. I believe this could also be shown in the profile information, as something like "Profiling range start" in the relative local time (or something better to clearly indicate that this is what the data contains, whether it's the really start of recording or what's left after the buffer was full and the oldest data needed to be discarded). The end (aka capture) time could also be shown. I will file another issue with these suggestions on Github.

• Meanwhile, the backend could record the timestamp when profiling starts, and we could output it (so the frontend could display the real "Recording started" time). But I'm not sure this would be as valuable as the profiling range start: If the profile buffer got full, it means that that start-of-recording time will be before the visible range. The main value may be to indicate to the profile-examiner that the profile may miss part of the profiling that was done at the start of the session, and maybe the user should increase the buffer size?

I'll call this bug "moved" as it will get handled on https://github.com/firefox-devtools/profiler/issues/3457

The follow-up issue https://github.com/firefox-devtools/profiler/issues/3458 (to add a correct "Recording started" field) may require some back-end work in which case we'd file a new bug for it (or reopen this one if appropriate).