Task duration should be coarsened for each context

[noamr]

Currently the report long tasks algorithm receives two timestamps and reports the duration separately for each BC. Since some BCs might need the timestamps to be coarsened, the TS passed here should be the unsafe shared current time, which means it would need to be coarsened separately for each BC.

[yoavweiss]

Given that the durations are times that are larger than 50ms, would it make sense to always coarsen the timestamps passed to the algorithm, for simplicity? I don't think there's any advantage/use-case here for more accurate timers.

[noamr]

Given that the durations are times that are larger than 50ms, would it make sense to always coarsen the timestamps passed to the algorithm, for simplicity? I don't think there's any advantage/use-case here for more accurate timers.

Yes I believe it's OK to have all of them as coarse.

[domenic]

Given that the durations are times that are larger than 50ms, would it make sense to always coarsen the timestamps passed to the algorithm, for simplicity?

My worry here is that coarsening is extremely implementation-defined, and includes jitter. E.g. consider a task which starts at t = 5 ms and ends at t = 60 ms, and thus is 55 ms long (over the 50 ms threshold). After applying jitter these timestamps could become t = 15 ms and t = 60 ms, thus only 45 ms (under the 50 ms threshold).

Or, if the implementation-defined time resolution in the coarsen time algorithm is more like 1 second (perhaps something a browser might do for background tabs), then those would both get coarsened to t = 0 ms, and thus the task would not be long. But a pair like t = 499 ms and t = 501 ms would get coarsened to t = 0 ms and t = 1000 ms.

[noamr]

Yes I'm not sure we need to simplify it that much. maybe it's better to send the unsafe high-res time to longtask and coarsen it per-document here. @yoavweiss ?

[yoavweiss]

@domenic - user agents vary in their coarsening and jitter applied, but they generally limit this to 1ms. As such a 49.5 ms task may be considered long in some UAs and not others, but since the LT limit is so much larger than the coarsening limits, I'm not sure that'd be an issue in practice.

At the same time, we could apply the coarsening at the API level if y'all think it's best.

[noamr]

I can see how sending coarse timestamps could make it seem like there is a 1ms regression in some cases where in fact there is a much smaller fluctuation. Also, for the sake of consistency maybe it's better to keep it like the other APIs where you coarsen based on COIC

[domenic]

user agents vary in their coarsening and jitter applied, but they generally limit this to 1ms.

If this could be stated somewhere in the spec that'd be especially useful :)

Anyway, I'm happy where this landed, for HTML integration purposes.