Re: [blink-dev] Intent to Prototype & Ship: Report Critical-CH caused restart in NavigationTiming

[Daniel Bratell]

LGTM3

/Daniel

On 2023-06-07 17:37, Philip Jägenstedt wrote:

LGTM2

On Wed, Jun 7, 2023 at 5:36 PM Chris Harrelson  
wrote:


Thanks! LGTM1

On Wed, Jun 7, 2023 at 6:55 AM Ari Chivukula
 wrote:

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
 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
 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
 wrote:

Hi Ari,
The documented process


 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
 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
 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
 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
  

Re: [blink-dev] Intent to Prototype & Ship: Report Critical-CH caused restart in NavigationTiming

[slightlyoff via Chromestatus]

LGTM2

-- 
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/8ec8e705fd8c2f42%40google.com.

Re: [blink-dev] Intent to Prototype & Ship: Report Critical-CH caused restart in NavigationTiming

[Philip Jägenstedt]

LGTM2

On Wed, Jun 7, 2023 at 5:36 PM Chris Harrelson 
wrote:

> Thanks! LGTM1
>
> On Wed, Jun 7, 2023 at 6:55 AM Ari Chivukula  wrote:
>
>> 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  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 
>>> 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 
 wrote:

> Hi Ari,
> The documented process
> 
>  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 
> 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 
>> 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
>>  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
>> 
>>
>> Motivation
>>
>> It’s possible for websites to observe a 

Re: [blink-dev] Intent to Prototype & Ship: Report Critical-CH caused restart in NavigationTiming

[Chris Harrelson]

Thanks! LGTM1

On Wed, Jun 7, 2023 at 6:55 AM Ari Chivukula  wrote:

> 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  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 
>> 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  wrote:
>>>
 Hi Ari,
 The documented process
 
  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 
 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 
> 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
>  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
> 
>
> Motivation
>
> It’s possible for websites to observe a change in the Navigation
> Timing  related to
> `responseStart` and `requestStart`, but there is no explicit 
> timestamp that
> indicates when this occurred. Without that it’s 

Re: [blink-dev] Intent to Prototype & Ship: Report Critical-CH caused restart in NavigationTiming

[Ari Chivukula]

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  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 
> 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  wrote:
>>
>>> Hi Ari,
>>> The documented process
>>> 
>>>  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 
>>> 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 
 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
  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
 

 Motivation

 It’s possible for websites to observe a change in the 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

Re: [blink-dev] Intent to Prototype & Ship: Report Critical-CH caused restart in NavigationTiming

[Rick Byers]

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  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  wrote:
>
>> Hi Ari,
>> The documented process
>> 
>>  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 
>> 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  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
>>>  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
>>> 
>>>
>>> Motivation
>>>
>>> It’s possible for websites to observe a change in the 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.
>>>
>>>
>>> 

Re: [blink-dev] Intent to Prototype & Ship: Report Critical-CH caused restart in NavigationTiming

[Ari Chivukula]

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  wrote:

> Hi Ari,
> The documented process
> 
>  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 
> 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  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
>>  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
>> 
>>
>> Motivation
>>
>> It’s possible for websites to observe a change in the 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
>> 

Re: [blink-dev] Intent to Prototype & Ship: Report Critical-CH caused restart in NavigationTiming

[Rick Byers]

Hi Ari,
The documented process

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  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  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
>  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
> 
>
> Motivation
>
> It’s possible for websites to observe a change in the 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
> 
>
> 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
>
> 

Re: [blink-dev] Intent to Prototype & Ship: Report Critical-CH caused restart in NavigationTiming

[Ari Chivukula]

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  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
  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
 

 Motivation

 It’s possible for websites to observe a change in the 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
 

 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
>> 
>> .
>>
>

-- 
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/CAGpy5D%2Bp-bt2-_CidOn-a5ek7%2B0_n_RWbsP1XTsJmiP5iu-NzQ%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype & Ship: Report Critical-CH caused restart in NavigationTiming

[Rick Byers]

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
>>>  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
>>> 
>>>
>>> Motivation
>>>
>>> It’s possible for websites to observe a change in the 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
>>> 
>>>
>>> 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
> 
> .
>

-- 
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/CAFUtAY8D6bF63u7yCk1gA_Sx7ODbKajckw%3D0hfAf25g5G1v%3D0A%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype & Ship: Report Critical-CH caused restart in NavigationTiming

['Ari Chivukula' via blink-dev]

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 
>>  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 
>> 
>>
>> Motivation
>>
>> It’s possible for websites to observe a change in the 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 
>> 
>>
>> 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.

Re: [blink-dev] Intent to Prototype & Ship: Report Critical-CH caused restart in NavigationTiming

[Alex Russell]

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
>
> aric...@chromium.org, miketa...@chromium.org, yoavwe...@chromium.org
>
> Specification
>
> https://github.com/w3c/navigation-timing/pull/188
>
> Summary
>
> Websites can indicate that a particular Client Hint 
>  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 
> 
>
> Motivation
>
> It’s possible for websites to observe a change in the 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 
> 
>
> 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/a6c272ec-57b0-4f2e-8cd6-e353edc546efn%40chromium.org.