#534: VisibilityStateEntry

Visit on Github.

Opened Jul 9, 2020

Saluton TAG!

I'm requesting a TAG review of VisibilityStateEntry.

Exposes the initial visibility state of the page plus any visibility state changes that the page goes through to the PerformanceObserver, with buffered flag support.

  • Explainer (minimally containing user needs and example code): url
  • Security and Privacy self-review: I did not fill it out because the API does not really expose information that is not already available via the PageVisibility API. But if desired I can fill it out.
  • GitHub repo (if you prefer feedback filed there): I will be adding this feature on this repo but feel free to comment on the doc or this issue for now.
  • Primary contacts (and their relationship to the specification):
    • Nicolás Peña Moreno, @npm1, Google, will do the spec work.
    • Ilya Grigorik, @igrigorik, Google, WebPerf chair.
    • Nic Jansma, @nicjansma, Akamai, WebPerf chair.
    • Yoav Weiss, @yoavweiss, Google, WebPerf chair.
  • Organization/project driving the design: Chromium
  • External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): Chrome implementation tracking bug Chrome status

Further details:

  • I have reviewed the TAG's API Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): W3C WebPerf WG
  • The group where standardization of this work is intended to be done ("unknown" if not known): W3C WebPerf WG
  • Existing major pieces of multi-stakeholder review or discussion of this design: see call minutes
  • Major unresolved issues with or opposition to this design: N/A
  • 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

Discussions

2020-08-03

Minutes

Ran out of time before we got to this.

2021-01-Kronos

Minutes

Rossen: David, there's a reply to your comment from the last time

David replies in https://github.com/w3ctag/design-reviews/issues/534#issuecomment-767216686

Rossen: also concerned about privacy. Pointed us to privacy section in page visibility spec. Could an author add entries that expose information that isn't currently detectable? Explainer says that this is the same information as page visibility.

David: same information, just with performance entries rather than events?

Rossen: ??? about ETW events in Windows, can be used for generic buffering of information. There's a hard requirement in that design that that they aren't used to drive any other behavior... so they might break.

... so when I read this... and hear David saying "they'd use the events for that case".... seems like they'd provide useful info to developers who want to optimize their pages, could also cause harm. On the other hand, we don't change the web platform that disruptively.

Rossen: if a window on Windows is minimized, and a user hovers and gets the preview, what does that imply about performance entries?

Rossen: seems like a good use case

David: I'm probably ok with closing this.

Rossen: throttling... other reasons for delays... not sure how it affects entry (or feature). If you have a process that's being suspended for some reason... when you're intending to navigate. E.g., on iOS, if I move from browser to different app, page load might be suspended by the OS. Then go back to Safari, and this is when they want the page visibility to fire... the intent of the proposal.

David: I think it should fire in that case... although maybe tab switching is a simpler case to think about?