GoogleChrome
Attributed task timestamps should begin at origin, not first task
https://github.com/GoogleChrome/lighthouse/blob/d956ec929d2b67028279f5e40d7e9a515a0b7404/lighthouse-core/lib/tracehouse/main-thread-tasks.js#L590-L593
It starts at first task ts, so it's usually close to the origin, but even with navigations there can often be a task (however short) on about:blank and so the task origin can be before the navigation even happens.
Easy to inject the time origin into the function, but it should probably also trim the tasks that will then have negative startTime as a result, either filtering the trace before creating the tasks or filtering the created tasks, making sure whichever is chosen still yields correct tasks.
Motivation here is that it makes attributed tasks much less usable in combination with the perf metrics in the same report because they're each using a different time origin, and there's no other info in the LHR that would give even the magnitude of the offset between the two of them (though I'm hoping it's typically 10s of ms or less).
#14252 fixed the timestamps, but left tasks with negative start/endTimes. This fixes analyses combining main-thread-tasks with metrics debugData and leaves everything else unchanged (since everything else currently only cares about durations, which don't change from a time origin shift).
To complete this issue we should drop any tasks before the timeOrigin from the various main-thread/bootup/third-party execution summaries so tasks not in the run aren't included in them.
To complete this issue we should drop any tasks before the timeOrigin from the various main-thread/bootup/third-party execution summaries so tasks not in the run aren't included in them.
Sg. But it also seems like this would rarely have impact in practice. It'd matter if we had long tasks while on about:blank yah? Properly "cropping" the trace sg though. The new trace model will make that easy for us.
We deprioritized cuz the most key stuff is done.
