Bugzilla

When markers were implemented with `MarkerPayload`-derived classes, some payloads had optional timing information, which could be output as JSON `null` for unspecified timestamps.
[The front-end relies on these `null`s when gauging the total visible range.](https://github.com/firefox-devtools/profiler/blob/19ba1208a5f540aa1caea80223401075e5dd307d/src/profile-logic/profile-data.js#L780-L801)

But since Markers 2.0 introduced better timing information (or maybe even before?), we now output unspecified timestamps as 0 (zero). This effectively forces all profiles to start at 0, which can be especially bad when most timestamps are later, e.g.: https://share.firefox.dev/2OCCOuF (the data is right at the end, around 27,000 seconds, but the range starts at 0)

In the code, [`MarkerTiming::GetStartTime()` and `GetEndTime()` return 0.0 for null timestamps](https://searchfox.org/mozilla-central/rev/b32d4ca055ca9cf717be480df640f8970724a0ce/mozglue/baseprofiler/public/BaseProfilerMarkersPrerequisites.h#371-385), instead we should return `Maybe<double>`, so that [`DeserializeAfterKindAndStream`](https://searchfox.org/mozilla-central/rev/b32d4ca055ca9cf717be480df640f8970724a0ce/mozglue/baseprofiler/public/BaseProfilerMarkersDetail.h#300,321-325) could output `null`s where appropriate.

It may also be possible for the front-end to fix "bad" profiles (from when this started until this fix lands), by detecting and ignoring unwanted zeroes.

When markers were implemented with `MarkerPayload`-derived classes, some payloads had optional timing information, which could be output as JSON `null` for unspecified timestamps.
[The front-end relies on these `null`s when gauging the total visible range.](https://github.com/firefox-devtools/profiler/blob/19ba1208a5f540aa1caea80223401075e5dd307d/src/profile-logic/profile-data.js#L780-L801)

But since Markers 2.0 introduced better timing information (or maybe even before?), we now output unspecified timestamps as 0 (zero). This effectively forces all profiles to start at 0, which can be especially bad when most timestamps are later, e.g.: https://share.firefox.dev/2OCCOuF (the data is right at the end, around 27,000 seconds, but the range starts at 0 -- Thanks @Bas for reporting this issue.)

In the code, [`MarkerTiming::GetStartTime()` and `GetEndTime()` return 0.0 for null timestamps](https://searchfox.org/mozilla-central/rev/b32d4ca055ca9cf717be480df640f8970724a0ce/mozglue/baseprofiler/public/BaseProfilerMarkersPrerequisites.h#371-385), instead we should return `Maybe<double>`, so that [`DeserializeAfterKindAndStream`](https://searchfox.org/mozilla-central/rev/b32d4ca055ca9cf717be480df640f8970724a0ce/mozglue/baseprofiler/public/BaseProfilerMarkersDetail.h#300,321-325) could output `null`s where appropriate.

It may also be possible for the front-end to fix "bad" profiles (from when this started until this fix lands), by detecting and ignoring unwanted zeroes.