I'm back! The code has been merged behind a flag w/ wpts: https://chromium-review.googlesource.com/c/chromium/src/+/4538244
The spec changes have been merged too: https://github.com/w3c/navigation-timing/pull/188 https://github.com/WICG/client-hints-infrastructure/pull/153 ~ Ari Chivukula (Their/There/They're) On Wed, Apr 19, 2023 at 12:02 PM Rick Byers <rby...@chromium.org> wrote: > Great, thanks Ari! No worries at all, checking to make sure the i's have > been dotted and t's have been crossed is what the API owners are here for > :-) > > On Wed, Apr 19, 2023 at 11:59 AM Ari Chivukula <aric...@chromium.org> > wrote: > >> Works for me, didn't realize that was the standard order. >> >> ~ Ari Chivukula (Their/There/They're) >> >> >> On Wed, Apr 19, 2023 at 11:58 AM Rick Byers <rby...@chromium.org> wrote: >> >>> Hi Ari, >>> The documented process >>> <https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship> >>> is >>> to land features and specs before requesting approval to ship, as that >>> gives the best possible chance for wide review and eventual interop. But we >>> unfortunately often find ourselves in the position that this is impractical >>> - eg. spec work blocked from landing due to lack of interest from a 2nd >>> implementor (WHATWG venue) or just very slow reviews. So, if necessary, we >>> are willing to approve based on a PR only but it's usually considered an >>> exceptional situation. None of those seem to be the case here, it's just >>> blocked on some impl and spec work right? In particular, we definitely want >>> to see WPTs landed prior to shipping, so we're aligned with Noam on that >>> request. chrishtr, foolip, yoav and I just discussed this now in the API >>> owners meeting and are aligned on this being standard practice (though >>> wouldn't be surprised if we've slipped up occasionally). >>> >>> Thanks, >>> Rick >>> >>> On Wed, Apr 19, 2023 at 11:34 AM Ari Chivukula <aric...@chromium.org> >>> wrote: >>> >>>> That differs from my past experience (in which a proposed spec change >>>> is sufficient to move forward with a launch), but if you want me to build >>>> and test it all behind a flag before I get the go ahead here that's fine. >>>> >>>> ~ Ari Chivukula (Their/There/They're) >>>> >>>> >>>> On Wed, Apr 19, 2023 at 11:32 AM Rick Byers <rby...@chromium.org> >>>> wrote: >>>> >>>>> This makes a lot of sense to me. Normally we prefer to approve >>>>> shipping only after spec PRs have landed, it looks like the PR is blocked >>>>> on some work from you including landing the WPTs, right? I'd suggest you >>>>> get this all landed under a status=experimental RuntimeEnabledFeature and >>>>> see if we can get the PR reviewed and landed in short order before trying >>>>> to flip to status=stable, WDYT? >>>>> >>>>> Rick >>>>> >>>>> On Wed, Apr 5, 2023 at 2:46 PM 'Ari Chivukula' via blink-dev < >>>>> blink-dev@chromium.org> wrote: >>>>> >>>>>> https://github.com/w3ctag/design-reviews/issues/833 >>>>>> >>>>>> On Wednesday, April 5, 2023 at 11:27:22 AM UTC-4 Alex Russell wrote: >>>>>> >>>>>>> Please file an issue with the TAG as an FYI and let us know when >>>>>>> they respond. Their job is to help us drive coherence across the >>>>>>> platform >>>>>>> and spot architectural patterns. There might be other occurances of >>>>>>> similar >>>>>>> oversights that they can help us spot and fix. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> On Tuesday, March 28, 2023 at 11:15:31 AM UTC-7 Ari Chivukula wrote: >>>>>>> >>>>>>>> Contact emails >>>>>>>> >>>>>>>> ari...@chromium.org, mike...@chromium.org, yoav...@chromium.org >>>>>>>> >>>>>>>> Specification >>>>>>>> >>>>>>>> https://github.com/w3c/navigation-timing/pull/188 >>>>>>>> >>>>>>>> Summary >>>>>>>> >>>>>>>> Websites can indicate that a particular Client Hint >>>>>>>> <https://wicg.github.io/client-hints-infrastructure/> is critical >>>>>>>> to the page by including it in a `Critical-CH` HTTP response header. >>>>>>>> Doing >>>>>>>> so will trigger a connection restart if the hint listed in the >>>>>>>> `Critical-CH` HTTP response header could be (but wasn’t) included in >>>>>>>> the >>>>>>>> HTTP request initially sent. This intent proposes adding `readonly >>>>>>>> attribute DOMHighResTimeStamp criticalCHRestart;` to the >>>>>>>> `PerformanceNavigationTiming` interface. >>>>>>>> >>>>>>>> >>>>>>>> Blink component >>>>>>>> >>>>>>>> Blink>PerformanceAPIs>NavigationTiming >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EPerformanceAPIs%3ENavigationTiming> >>>>>>>> >>>>>>>> Motivation >>>>>>>> >>>>>>>> It’s possible for websites to observe a change in the Navigation >>>>>>>> Timing <https://github.com/w3c/navigation-timing> related to >>>>>>>> `responseStart` and `requestStart`, but there is no explicit timestamp >>>>>>>> that >>>>>>>> indicates when this occurred. Without that it’s harder for sites to >>>>>>>> detect >>>>>>>> the impact that the `Critical-CH` HTTP response header has on >>>>>>>> connections. Developers (including Akamai) are interested in using >>>>>>>> this to >>>>>>>> better understand the impact of User Agent Client Hints / User Agent >>>>>>>> Reduction. >>>>>>>> >>>>>>>> `criticalCHRestart` can only be set for top-level frames, as >>>>>>>> subresources and iframes ignore `Critical-CH` HTTP response >>>>>>>> headers. >>>>>>>> >>>>>>>> TAG review >>>>>>>> >>>>>>>> N/A, this is a small, incremental addition to an existing feature >>>>>>>> for convenience and the loaded website has other (less convenient) >>>>>>>> ways to >>>>>>>> detect a Critical-CH restart. >>>>>>>> >>>>>>>> >>>>>>>> Compatibility & Interoperability >>>>>>>> >>>>>>>> We would be the first to implement if approved. >>>>>>>> >>>>>>>> >>>>>>>> Gecko: https://github.com/mozilla/standards-positions/issues/767 >>>>>>>> >>>>>>>> >>>>>>>> WebKit: https://github.com/WebKit/standards-positions/issues/156 >>>>>>>> >>>>>>>> >>>>>>>> Web Developers: Requested by Akamai >>>>>>>> <https://github.com/w3c/navigation-timing/issues/177> >>>>>>>> >>>>>>>> Is this feature fully tested by web-platform-tests? >>>>>>>> >>>>>>>> No, but it will be. >>>>>>>> >>>>>>>> Tracking bug >>>>>>>> >>>>>>>> https://crbug.com/1425910 >>>>>>>> >>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>> >>>>>>>> https://chromestatus.com/feature/5140317616996352 >>>>>>>> >>>>>>>> -- >>>>>> 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/0dacf540-c8be-4096-9ad1-bc7a99af630cn%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0dacf540-c8be-4096-9ad1-bc7a99af630cn%40chromium.org?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/CAGpy5DKthEYQEYGqoFyVWsp0xnm24QLEJfEoeZz9ZKB39PKtkg%40mail.gmail.com.
