Feedback about message-event-timing proposal

Feedback on this proposal

• I like and appreciate that this is an extension of Event Timing, rather than addition to it. The model of reporting events is similar, but the attribution details and reporting details differ too much to merge.

• I like that there is 200ms durationThreshold. I don't know if that is the right number, but it seems valuable to me to throttle at a fairly large number.

  • ...However, the duration of a message is the combined sum of time that include "input delay". I worry that a single long message (serialization or processing time) might block the message event queue for many other fast events, and each one would potentially pass the 200ms duration.
  • In other words, is there any way to identify a specific message that backed up the queue, rather than all messages that suffered because of a backed up queue?
  • An even simpler example: any long task on a receiving thread would cause all pending messages to become long and reported. This would place blame in the wrong area.

• You say:

  most postMessage events are ultimately triggered by user interaction

  but I am not sure if this is true? And even if it were, your proposal does not limit messages sent from the context a truster UI event listener / interaction, and exposes an interactionId of 0 always. I think this means that a developer can send very many messages programatically, and then expect careful timing for them.

Net/net, I think I like the design, and some of the attributes you consider reporting sound like useful data which I can see helping specific app developers.

On the other hand, I think that the related proposal for congested moments fundamentally addresses some of the above concerns. I wonder if the extra attribution data you need cannot be added to the "Long Scripts" attribution metadata.

Could it be useful to loop back to this proposal after making progress on this other one and see how many gaps remain?

Start with message-event-timing/explainer.md, then compare loaf-congested-moments/explainer.md and the referenced Long Scripts attribution metadata. Examine whether queue-backup attribution and programmatic-message timing gaps are covered. Done means documenting the remaining design gaps and a clear direction for the proposal.