Brendan Kenny
Brendan Kenny
> I tried testing another page and having multiple process ids per thread seems normal. Doesn't address the root issue, but for this, you need the (pid, tid) tuple to...
This is a really old problem of audit paths vs audit IDs. Really we need to fix that problem, otherwise everything should really accept paths or IDs (which would just...
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...
#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...
a few things that came up today: - having a standalone TargetManager is great. The legacy auto attach logic is diffuse and appears general (e.g. we allow `sendCommand` to arbitrary...
> Do you want to revert back to the old smoke expectations to see how robust it is? did you end up trying this?
Wasn't the point of this change that there shouldn't be any differences now?
> point was to just prevent the dependence on chrome doing...whatever it was doing that resulted in multiple execution ids being created before LH starts. Which would have been tested...
added some thoughts to #14127 about the approach
> > add a metric N/A state (that's not notApplicable) in the report perf category renderer for when there was no user input in the trace > > What's wrong...