LGTM1

Please send a webkit position for this, even if it is non-blocking.


On Wed, Apr 26, 2023 at 5:53 PM Noam Rosenthal <nrosent...@chromium.org>
wrote:

>
>
> On Wed, Apr 26, 2023 at 1:28 PM Yoav Weiss <yoavwe...@chromium.org> wrote:
>
>> Thanks for pushing this over the line!!
>>
>> On Tue, Apr 25, 2023 at 10:26 AM Noam Rosenthal <nrosent...@chromium.org>
>> wrote:
>>
>>> Contact emails...@chromium.org, nrosent...@chromium.org
>>>
>>> Explainer
>>> https://docs.google.com/document/d/1l5kHiJRkdQwEN-CYI5_mUNODhQVB5rCyjN4jHDdXDHA/edit#
>>>
>>> Specificationhttps://github.com/whatwg/html/pull/8206
>>>
>>
>> What's preventing the PR from landing?
>>
> Nothing at all. Sending this I2S is part of showing that Chrome is going
> to ship this. Was planning on merging the enabled-by-default CL after the
> spec PR is merged.
>
>
>>
>>
>>>
>>>
>>> Summary
>>>
>>> Exposes to PerformanceObserver the initial visibility state of a page
>>> plus any visibility state changes that the page goes through. Also adds
>>> support for this to the observe() method's buffered flag.
>>>
>>>
>>> Blink componentBlink>PerformanceAPIs
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EPerformanceAPIs>
>>>
>>> Search tagsvisibility
>>> <https://chromestatus.com/features#tags:visibility>
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/534
>>>
>>> TAG review statusIssues addressed
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Low risk, as this API should not be user-visible and we expect other
>>> major browser vendors to implement the API at some point, as they all
>>> currently implement document.visibilityState. This API has been discussed
>>> in the W3C WebPerf WG. Minutes here:
>>> https://docs.google.com/document/d/1PMbJ8kUHtrrCZxHJfKXcV0YQeTxyMOH4AORgd2VuhOw/edit
>>>
>>>
>>> *Gecko*: Positive (
>>> https://github.com/whatwg/html/pull/8206#issuecomment-1499406083)
>>>
>>> *WebKit*: No signal
>>>
>>
>> Can we ask for a signal?
>>
>>
>>>
>>> *Web developers*: No signals
>>>
>>
>> I think Meta's request for this (even if old) can count as a positive
>> signal.
>>
>>
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> This will frequently be used in tandem with other performance APIs, so
>>> the choice to integrate with PerformanceObserver seems natural in that
>>> regard.
>>>
>>>
>>> Activation
>>>
>>> This can already be somewhat polyfilled by appending a very early
>>> JavaScript snippet to the page, querying document.visibilityState, and
>>> registering an onvisibilitychange event handler.
>>>
>>>
>>> Security
>>>
>>> This API does not introduce any security/privacy risks that would not be
>>> already present with the Page Visibility API.
>>>
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> N/A
>>>
>>>
>>> Debuggability
>>>
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>> ?Yes
>>>
>>> Flag nameVisibilityStateEntry
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1103451
>>>
>>> MeasurementNew UseCounter has been added for visibility-state observers.
>>>
>>> Availability expectationWill be available in all browsers once shipped
>>>
>>> Adoption expectationFeature was requested by big partners such as
>>> Facebook, and matches some of the expectations of RUM providers.
>>>
>>> Adoption planThis is a small feature, probably a short blog + MDN
>>> update will do.
>>>
>>> Estimated milestones
>>> Shipping on desktop 115
>>> Shipping on Android 115
>>> Shipping on WebView 115
>>>
>>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or
>>> interop issues. Please list open issues (e.g. links to known github issues
>>> in the project for the feature specification) whose resolution may
>>> introduce web compat/interop risk (e.g., changing to naming or structure of
>>> the API in a non-backward-compatible way).
>>> https://github.com/whatwg/html/pull/8206
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5683502144028672
>>>
>>> Links to previous Intent discussions
>>>
>>> This intent message was generated by Chrome Platform Status
>>> <https://chromestatus.com/>.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYaRn4fPjxGmtLT4zTEUfq-r4esCpfU8EU36FhnNk4CGag%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYaRn4fPjxGmtLT4zTEUfq-r4esCpfU8EU36FhnNk4CGag%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWfyDdaf9oC8_tWC3o41fC0oy60iqZkwN%2B6ZtzEF79LkQ%40mail.gmail.com.

Reply via email to