Saluton TAG!

I'm requesting a TAG review of hasDroppedEntry in PerformanceObserverCallback.

[One paragraph summary of idea, ideally copy-pasted from Explainer introduction] Currently, web developers can use PerformanceObserver with buffered flag to listen to past and future performance entries about their site. However, past entries need to be stored, and there is a buffer size limit. The hasDroppedEntry boolean flag helps developers know if they may have lost an entry due to this storage being full. It's set to true when there exists an entryType being observed for which an entry got dropped from the buffer due to such buffer being full.

• Explainer¹ (minimally containing user needs and example code): https://github.com/npm1/hasDroppedEntry/blob/master/README.md
• Specification URL: The flag has been added to the PerformanceObserverCallback: https://w3c.github.io/performance-timeline/#dom-performanceobservercallback. The additional processing logic can be followed from the steps computing hasDroppedEntry in https://w3c.github.io/performance-timeline/#ref-for-dfn-queue-the-performanceobserver-task-2.
• Tests: not yet available.
• Security and Privacy self-review²: https://github.com/npm1/hasDroppedEntry/blob/master/security-and-privacy.md
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/performance-timeline
• Primary contacts (and their relationship to the specification):
  • Nicolás Peña Moreno @npm1, Google, wrote the change being reviewed
  • Yoav Weiss @yoavweiss, Google, W3C WebPerf chair
• Organization(s)/project(s) driving the specification: Google (and this change was discussed at W3C WebPerf WG).
• Key pieces of existing multi-stakeholder review or discussion of this specification: issue was filed at https://github.com/w3c/performance-timeline/issues/169, minutes of WebPerf discussion at https://docs.google.com/document/d/e/2PACX-1vQE0yblkBXaUueIEHhmtH36ccxDVmY48ivhPFNOV4m2k9mjbmRXsBWK5b39UM33ay5X8rSUw3IwuBXw/pub
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): this was recently added so no implementation is ongoing yet. Chrome status entry can be found at https://www.chromestatus.com/feature/5663336802811904.

Further details:

• I have reviewed the TAG's API Design Principles
• Relevant time constraints or deadlines: none
• The group where the work on this specification is currently being done: WebPerf WG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WebPerf WG
• Major unresolved issues with or opposition to this specification: none (though there are various design choices to expose this information, so feedback there is welcome).
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @npm1

---

CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING

Please preview the issue and check that the links work before submitting.

In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer fully public documents though, since we work in the open.

¹ We require an explainer to give the relevant context for the spec review, even if the spec has some background information. For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.

² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.