PerformanceEntry.id is shadowed by PerformanceElementTiming.id.

[powdercloud]

PerformanceEntry is defined here:
https://w3c.github.io/performance-timeline/#the-performanceentry-interface

PerformanceElementTiming is defined here:
https://w3c.github.io/element-timing/#sec-performance-element-timing

PerformanceElementTiming extends PerformanceEntry - yet both define an id attribute, with different types and different meaning.

interface PerformanceEntry {
  readonly    attribute unsigned long long  id;
...

interface PerformanceElementTiming : PerformanceEntry {
    ...
    readonly attribute [DOMString] id;
...

Looking at both specifications, the id in PerformanceElementTiming appears more useful - it is set to the id of the element that was observed; whereas, the id in Performance entry is some number that increments between subsequent entries, with no further meaning except that it currently takes part in initializing the PerformanceEntry.navigationId (see Step 5 of https://w3c.github.io/performance-timeline/#queue-a-performanceentry).

Therefore, I'm thinking it would be best to remove PerformanceEntry.id, and slightly rephrase the mechanism for assigning PerformanceEntry.navigationId so that it no longer references that attribute.

Please let me know what you think.

Additional references:

• https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEntry
• https://developer.mozilla.org/en-US/docs/Web/API/PerformanceElementTiming/id

[npm1]

Yea incorrectly added in #192. I don't think Chrome shipped the PerformanceEntry id, it should be removed from the spec. https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/timing/performance_entry.idl

[mmocny]

Thanks @npm1 for chiming in!

I wonder if you or @clelland recall: was there an explicit design goal with introducing an id type for every PerformanceEntry (distinct from navigationId)?

One reason might be to help with ordering, without relying on startTime.

For example, in Event Timing, it is possible for two sequential events (as per event dispatch / event processing time) to actually not have sequential timeStamp values, and so therefore not have a sequential startTime values [1].

Because we currently try to keep performance entries sorted by startTime, this means reporting isn't actually always in "entry creation" order. Though probably we could solve that without adding an id...

---

[1]: Potentially this could happen if the browser process observes these events in one order, but the hardware timestamps are another order-- especially if using two different input modalities.
But more commonly this happens when we have synthetic events, where the hardware timeStamp is actually somewhat artificially defined in terms of other event timings, and so you have can have a mix of "real" and "synthetic" values.

[mmocny]

I'll take a stab to clean this up, together with removing navigationId from this spec. That work is still part of a wicg project (soft-navigations) and I think that there should be a more generalized approach specific to the performance timeline (something that works for bfcache, prerendering, but maybe also visibilitychange...) and navigationId might not be the right term for that.