Re: [blink-dev] Intent to Ship: Navigation API

2022-04-20 Thread Mike West 
LGTM3.

-mike

On Wednesday, April 20, 2022 at 1:57:48 PM UTC+2 Yoav Weiss wrote:

> LGTM2
>
> I share MikeT's excitement about this API, and hopeful it can provide both 
> ergonomics wins for developers as well as predictability wins for browsers 
> when it comes to SPAs and navigations.
>
> On Monday, April 18, 2022 at 5:47:45 PM UTC+2 Mike Taylor wrote:
>
>> LGTM1 - I'm excited about this API, and hopeful we can smooth over the 
>> subtle interop issues that you've documented. But I see this as a huge 
>> ergonomics win over the status quo, and am encouraged by the careful work 
>> y'all have done.
>>
>> On 4/18/22 11:39 AM, Domenic Denicola wrote:
>>
>>
>>
>> On Mon, Apr 18, 2022 at 10:49 AM Mike Taylor  
>> wrote:
>>
>>> On 4/12/22 12:08 PM, Domenic Denicola wrote:
>>>
>>> Contact emails 
>>>
>>> dome...@chromium.org, jap...@chromium.org
>>>
>>> Explainer 
>>>
>>> https://github.com/WICG/navigation-api/blob/main/README.md
>>>
>>> (Aside: This explainer is a master-class in writing explainers. 
>>> Incredibly well done - I really appreciate the effort that went into this).
>>>
>>>
>>> Specification 
>>>
>>> https://wicg.github.io/navigation-api/
>>>
>>> Summary 
>>>
>>> The window.navigation API provides the ability to intercept and initiate 
>>> navigations, as well as introspect an application's history entries. This 
>>> provides a more useful alternative to window.history and window.location, 
>>> specifically aimed at the needs of single-page web applications.
>>>
>>> (Note: this API was formerly known as the app history API.)
>>>
>>> Blink component 
>>>
>>> Blink>History 
>>> 
>>>
>>> TAG review 
>>>
>>> https://github.com/w3ctag/design-reviews/issues/605
>>>
>>> https://github.com/w3ctag/design-reviews/issues/717
>>>
>>> TAG review status 
>>>
>>> Issues addressed
>>>
>>> Link to origin trial feedback summary 
>>>
>>>
>>> https://docs.google.com/document/d/1oDtVhNJaDyEAqsthe07wJaGNVpt-g4TLB4A0-lU2lr4/edit?usp=sharing
>>>
>>> Risks 
>>> Interoperability 
>>>
>>> The biggest interoperability risk with this API is that it is building 
>>> on a rocky foundation. The existing session history spec does not match 
>>> browsers very well, and browsers do not match each other. Since this new 
>>> API layers on top of the existing model, this could cause issues.
>>>
>>> We have attempted to address this via a solid and well-tested 
>>> specification for the new API, as well as ongoing efforts in whatwg/html 
>>> PR #6315  and elsewhere on 
>>> the HTML Standard issue tracker 
>>> 
>>>  
>>> to reform the foundational parts of the specification. For example, 
>>> although the navigation API's new events, such as currententrychange, are 
>>> fired at well-specified times, there is an existing interop problem 
>>>  regarding the timing of 
>>> popstate vs. hashchange events, which makes it difficult to write tests for 
>>> the ordering of currententrychange vs. hashchange/popstate. Working on such 
>>> existing interop issues and specification problems, and then expanding the 
>>> navigation API test suite to cover any such interactions, is our team's top 
>>> priority after this launch. See also this tracking issue 
>>> .
>>>
>>> I do have slight concerns 
>>>  
>>> over the popstate/hashchange event change - I fear that might result in 
>>> more back button traps for Chromium users (that sadly Gecko users 
>>> experience today). But I could be wrong - do you have any plans to measure 
>>> and monitor abuse? Or do we have existing metrics?
>>>
>>
>> To make sure we are on the same page: at this point we are discussing a 
>> future Intent to Ship about a separate behavior change, and we are not 
>> discussing the Navigation API.
>>
>> Correct - and to be extra clear, any potential future I2S is not 
>> influencing this I2S in my mind.
>>
>> Our plan for that future Intent to Ship does indeed involve careful 
>> monitoring. However I don't think it has any chance of increasing 
>> back-trapping. Deterministically firing the events in the order (sync 
>> popstate, async hashchange) like Gecko does, instead of Chrome's version 
>> where sometimes it's (async popstate, async hashchange) and sometimes it's 
>> (async hashchange, async popstate) depending on network conditions and page 
>> size, should not increase back-trapping. 
>>
>> OK, I'm very happy to be wrong here. :)
>>
>>
>>> Regarding whether this new API will be implemented in other browsers, we 
>>> have been encouraged by the consistent and positive collaboration with 
>>> Gecko engineers, which has led to several API

Re: [blink-dev] Intent to Ship: Navigation API

2022-04-20 Thread Yoav Weiss 
LGTM2

I share MikeT's excitement about this API, and hopeful it can provide both 
ergonomics wins for developers as well as predictability wins for browsers 
when it comes to SPAs and navigations.

On Monday, April 18, 2022 at 5:47:45 PM UTC+2 Mike Taylor wrote:

> LGTM1 - I'm excited about this API, and hopeful we can smooth over the 
> subtle interop issues that you've documented. But I see this as a huge 
> ergonomics win over the status quo, and am encouraged by the careful work 
> y'all have done.
>
> On 4/18/22 11:39 AM, Domenic Denicola wrote:
>
>
>
> On Mon, Apr 18, 2022 at 10:49 AM Mike Taylor  
> wrote:
>
>> On 4/12/22 12:08 PM, Domenic Denicola wrote:
>>
>> Contact emails 
>>
>> dome...@chromium.org, jap...@chromium.org
>>
>> Explainer 
>>
>> https://github.com/WICG/navigation-api/blob/main/README.md
>>
>> (Aside: This explainer is a master-class in writing explainers. 
>> Incredibly well done - I really appreciate the effort that went into this).
>>
>>
>> Specification 
>>
>> https://wicg.github.io/navigation-api/
>>
>> Summary 
>>
>> The window.navigation API provides the ability to intercept and initiate 
>> navigations, as well as introspect an application's history entries. This 
>> provides a more useful alternative to window.history and window.location, 
>> specifically aimed at the needs of single-page web applications.
>>
>> (Note: this API was formerly known as the app history API.)
>>
>> Blink component 
>>
>> Blink>History 
>> 
>>
>> TAG review 
>>
>> https://github.com/w3ctag/design-reviews/issues/605
>>
>> https://github.com/w3ctag/design-reviews/issues/717
>>
>> TAG review status 
>>
>> Issues addressed
>>
>> Link to origin trial feedback summary 
>>
>>
>> https://docs.google.com/document/d/1oDtVhNJaDyEAqsthe07wJaGNVpt-g4TLB4A0-lU2lr4/edit?usp=sharing
>>
>> Risks 
>> Interoperability 
>>
>> The biggest interoperability risk with this API is that it is building on 
>> a rocky foundation. The existing session history spec does not match 
>> browsers very well, and browsers do not match each other. Since this new 
>> API layers on top of the existing model, this could cause issues.
>>
>> We have attempted to address this via a solid and well-tested 
>> specification for the new API, as well as ongoing efforts in whatwg/html 
>> PR #6315  and elsewhere on the 
>> HTML Standard issue tracker 
>> 
>>  
>> to reform the foundational parts of the specification. For example, 
>> although the navigation API's new events, such as currententrychange, are 
>> fired at well-specified times, there is an existing interop problem 
>>  regarding the timing of 
>> popstate vs. hashchange events, which makes it difficult to write tests for 
>> the ordering of currententrychange vs. hashchange/popstate. Working on such 
>> existing interop issues and specification problems, and then expanding the 
>> navigation API test suite to cover any such interactions, is our team's top 
>> priority after this launch. See also this tracking issue 
>> .
>>
>> I do have slight concerns 
>>  
>> over the popstate/hashchange event change - I fear that might result in 
>> more back button traps for Chromium users (that sadly Gecko users 
>> experience today). But I could be wrong - do you have any plans to measure 
>> and monitor abuse? Or do we have existing metrics?
>>
>
> To make sure we are on the same page: at this point we are discussing a 
> future Intent to Ship about a separate behavior change, and we are not 
> discussing the Navigation API.
>
> Correct - and to be extra clear, any potential future I2S is not 
> influencing this I2S in my mind.
>
> Our plan for that future Intent to Ship does indeed involve careful 
> monitoring. However I don't think it has any chance of increasing 
> back-trapping. Deterministically firing the events in the order (sync 
> popstate, async hashchange) like Gecko does, instead of Chrome's version 
> where sometimes it's (async popstate, async hashchange) and sometimes it's 
> (async hashchange, async popstate) depending on network conditions and page 
> size, should not increase back-trapping. 
>
> OK, I'm very happy to be wrong here. :)
>
>
>> Regarding whether this new API will be implemented in other browsers, we 
>> have been encouraged by the consistent and positive collaboration with 
>> Gecko engineers, which has led to several API changes and a good amount of 
>> review. (We have no signal from WebKit.)
>>
>> Compatibility
>>
>> This has been the team's main focus for the last few months, as we burned 
>> through the list of

Re: [blink-dev] Intent to Ship: Navigation API

2022-04-18 Thread Mike Taylor 
LGTM1 - I'm excited about this API, and hopeful we can smooth over the 
subtle interop issues that you've documented. But I see this as a huge 
ergonomics win over the status quo, and am encouraged by the careful 
work y'all have done.


On 4/18/22 11:39 AM, Domenic Denicola wrote:



On Mon, Apr 18, 2022 at 10:49 AM Mike Taylor  
wrote:


On 4/12/22 12:08 PM, Domenic Denicola wrote:



Contact emails

dome...@chromium.org, jap...@chromium.org


Explainer

https://github.com/WICG/navigation-api/blob/main/README.md



(Aside: This explainer is a master-class in writing explainers.
Incredibly well done - I really appreciate the effort that went
into this).



Specification

https://wicg.github.io/navigation-api/



Summary

The window.navigation API provides the ability to intercept and
initiate navigations, as well as introspect an application's
history entries. This provides a more useful alternative to
window.history and window.location, specifically aimed at the
needs of single-page web applications.


(Note: this API was formerly known as the app history API.)


Blink component

Blink>History




TAG review

https://github.com/w3ctag/design-reviews/issues/605


https://github.com/w3ctag/design-reviews/issues/717



TAG review status

Issues addressed


Link to origin trial feedback summary


https://docs.google.com/document/d/1oDtVhNJaDyEAqsthe07wJaGNVpt-g4TLB4A0-lU2lr4/edit?usp=sharing




Risks


Interoperability

The biggest interoperability risk with this API is that it is
building on a rocky foundation. The existing session history spec
does not match browsers very well, and browsers do not match each
other. Since this new API layers on top of the existing model,
this could cause issues.


We have attempted to address this via a solid and well-tested
specification for the new API, as well as ongoing efforts in
whatwg/html PR #6315
and elsewhere on the
HTML Standard issue tracker

to
reform the foundational parts of the specification. For example,
although the navigation API's new events, such as
currententrychange, are fired at well-specified times, there is
an existing interop problem
regarding the timing
of popstate vs. hashchange events, which makes it difficult to
write tests for the ordering of currententrychange vs.
hashchange/popstate. Working on such existing interop issues and
specification problems, and then expanding the navigation API
test suite to cover any such interactions, is our team's top
priority after this launch. See also this tracking issue
.


I do have slight concerns

over the popstate/hashchange event change - I fear that might
result in more back button traps for Chromium users (that sadly
Gecko users experience today). But I could be wrong - do you have
any plans to measure and monitor abuse? Or do we have existing
metrics?


To make sure we are on the same page: at this point we are discussing 
a future Intent to Ship about a separate behavior change, and we are 
not discussing the Navigation API.


Correct - and to be extra clear, any potential future I2S is not 
influencing this I2S in my mind.


Our plan for that future Intent to Ship does indeed involve careful 
monitoring. However I don't think it has any chance of increasing 
back-trapping. Deterministically firing the events in the order (sync 
popstate, async hashchange) like Gecko does, instead of Chrome's 
version where sometimes it's (async popstate, async hashchange) and 
sometimes it's (async hashchange, async popstate) depending on network 
conditions and page size, should not increase back-trapping.

OK, I'm very happy to be wrong here. :)




Regarding whether this new API will be implemented in other
browsers, we have been encouraged by the consistent and positive
collaboration with Gecko engineers, which has led to several API
changes and a good amount of review. (We have no signal from WebKit.)


Compatibility

This has

Re: [blink-dev] Intent to Ship: Navigation API

2022-04-18 Thread Domenic Denicola 
On Mon, Apr 18, 2022 at 10:49 AM Mike Taylor  wrote:

> On 4/12/22 12:08 PM, Domenic Denicola wrote:
>
> Contact emails
>
> dome...@chromium.org, jap...@chromium.org
>
> Explainer
>
> https://github.com/WICG/navigation-api/blob/main/README.md
>
> (Aside: This explainer is a master-class in writing explainers. Incredibly
> well done - I really appreciate the effort that went into this).
>
>
> Specification
>
> https://wicg.github.io/navigation-api/
>
> Summary
>
> The window.navigation API provides the ability to intercept and initiate
> navigations, as well as introspect an application's history entries. This
> provides a more useful alternative to window.history and window.location,
> specifically aimed at the needs of single-page web applications.
>
> (Note: this API was formerly known as the app history API.)
>
> Blink component
>
> Blink>History
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/605
>
> https://github.com/w3ctag/design-reviews/issues/717
>
> TAG review status
>
> Issues addressed
>
> Link to origin trial feedback summary
>
>
> https://docs.google.com/document/d/1oDtVhNJaDyEAqsthe07wJaGNVpt-g4TLB4A0-lU2lr4/edit?usp=sharing
>
> Risks
> Interoperability
>
> The biggest interoperability risk with this API is that it is building on
> a rocky foundation. The existing session history spec does not match
> browsers very well, and browsers do not match each other. Since this new
> API layers on top of the existing model, this could cause issues.
>
> We have attempted to address this via a solid and well-tested
> specification for the new API, as well as ongoing efforts in whatwg/html
> PR #6315  and elsewhere on the
> HTML Standard issue tracker
> 
> to reform the foundational parts of the specification. For example,
> although the navigation API's new events, such as currententrychange, are
> fired at well-specified times, there is an existing interop problem
>  regarding the timing of
> popstate vs. hashchange events, which makes it difficult to write tests for
> the ordering of currententrychange vs. hashchange/popstate. Working on such
> existing interop issues and specification problems, and then expanding the
> navigation API test suite to cover any such interactions, is our team's top
> priority after this launch. See also this tracking issue
> .
>
> I do have slight concerns
>  over
> the popstate/hashchange event change - I fear that might result in more
> back button traps for Chromium users (that sadly Gecko users experience
> today). But I could be wrong - do you have any plans to measure and monitor
> abuse? Or do we have existing metrics?
>

To make sure we are on the same page: at this point we are discussing a
future Intent to Ship about a separate behavior change, and we are not
discussing the Navigation API.

Our plan for that future Intent to Ship does indeed involve careful
monitoring. However I don't think it has any chance of increasing
back-trapping. Deterministically firing the events in the order (sync
popstate, async hashchange) like Gecko does, instead of Chrome's version
where sometimes it's (async popstate, async hashchange) and sometimes it's
(async hashchange, async popstate) depending on network conditions and page
size, should not increase back-trapping.


>
> Regarding whether this new API will be implemented in other browsers, we
> have been encouraged by the consistent and positive collaboration with
> Gecko engineers, which has led to several API changes and a good amount of
> review. (We have no signal from WebKit.)
>
> Compatibility
>
> This has been the team's main focus for the last few months, as we burned
> through the list of potentially-compat-impacting issues
> . In collaboration
> with Gecko this led to several improvements, such as the API rename (from
> app history), a change 
> in how replacement navigations are requested, and the addition
>  of an indicator for
> when a download is requested. We believe the remaining issues (3 at the
> time of writing) are manageable:
>
>
>-
>
>#72 : this will
>result in firing an event more often during extreme edge case scenarios
>involving replacement navigations, or in less-rare-but-still-rare scenarios
>involving the user clearing their history. Neither case should prove
>problematic.
>-
>
>#207

Re: [blink-dev] Intent to Ship: Navigation API

2022-04-18 Thread Mike Taylor 

On 4/12/22 12:08 PM, Domenic Denicola wrote:



Contact emails

dome...@chromium.org, jap...@chromium.org


Explainer

https://github.com/WICG/navigation-api/blob/main/README.md 



(Aside: This explainer is a master-class in writing explainers. 
Incredibly well done - I really appreciate the effort that went into this).



Specification

https://wicg.github.io/navigation-api/ 




Summary

The window.navigation API provides the ability to intercept and 
initiate navigations, as well as introspect an application's history 
entries. This provides a more useful alternative to window.history and 
window.location, specifically aimed at the needs of single-page web 
applications.



(Note: this API was formerly known as the app history API.)


Blink component

Blink>History 




TAG review

https://github.com/w3ctag/design-reviews/issues/605 



https://github.com/w3ctag/design-reviews/issues/717 




TAG review status

Issues addressed


Link to origin trial feedback summary

https://docs.google.com/document/d/1oDtVhNJaDyEAqsthe07wJaGNVpt-g4TLB4A0-lU2lr4/edit?usp=sharing 




Risks


Interoperability

The biggest interoperability risk with this API is that it is building 
on a rocky foundation. The existing session history spec does not 
match browsers very well, and browsers do not match each other. Since 
this new API layers on top of the existing model, this could cause issues.



We have attempted to address this via a solid and well-tested 
specification for the new API, as well as ongoing efforts in 
whatwg/html PR #6315 and 
elsewhere on the HTML Standard issue tracker 
to 
reform the foundational parts of the specification. For example, 
although the navigation API's new events, such as currententrychange, 
are fired at well-specified times, there is an existing interop 
problem regarding the 
timing of popstate vs. hashchange events, which makes it difficult to 
write tests for the ordering of currententrychange vs. 
hashchange/popstate. Working on such existing interop issues and 
specification problems, and then expanding the navigation API test 
suite to cover any such interactions, is our team's top priority after 
this launch. See also this tracking issue 
.


I do have slight concerns 
 
over the popstate/hashchange event change - I fear that might result in 
more back button traps for Chromium users (that sadly Gecko users 
experience today). But I could be wrong - do you have any plans to 
measure and monitor abuse? Or do we have existing metrics?


Regarding whether this new API will be implemented in other browsers, 
we have been encouraged by the consistent and positive collaboration 
with Gecko engineers, which has led to several API changes and a good 
amount of review. (We have no signal from WebKit.)



Compatibility

This has been the team's main focus for the last few months, as we 
burned through the list of potentially-compat-impacting issues 
. In collaboration 
with Gecko this led to several improvements, such as the API rename 
(from app history), a change 
in how replacement 
navigations are requested, and the addition 
of an indicator for 
when a download is requested. We believe the remaining issues (3 at 
the time of writing) are manageable:



 *

#72 : this will
result in firing an event more often during extreme edge case
scenarios involving replacement navigations, or in
less-rare-but-still-rare scenarios involving the user clearing
their history. Neither case should prove problematic.

 *

#207 : the most
likely solution will either be leaving things as they are, or
changing the timing of an event in a way that will not disturb
"normal" usage of the API. Although such a timing change could be
risky if this API had wide deployment, we believe that changing
the timing within a milestone or three would not be problematic if
it ends up being desirable.

 *

#202

[blink-dev] Intent to Ship: Navigation API

2022-04-12 Thread Domenic Denicola 
Contact emails

dome...@chromium.org, jap...@chromium.org

Explainer

https://github.com/WICG/navigation-api/blob/main/README.md

Specification

https://wicg.github.io/navigation-api/

Summary

The window.navigation API provides the ability to intercept and initiate
navigations, as well as introspect an application's history entries. This
provides a more useful alternative to window.history and window.location,
specifically aimed at the needs of single-page web applications.

(Note: this API was formerly known as the app history API.)

Blink component

Blink>History


TAG review

https://github.com/w3ctag/design-reviews/issues/605

https://github.com/w3ctag/design-reviews/issues/717

TAG review status

Issues addressed

Link to origin trial feedback summary

https://docs.google.com/document/d/1oDtVhNJaDyEAqsthe07wJaGNVpt-g4TLB4A0-lU2lr4/edit?usp=sharing

Risks
Interoperability

The biggest interoperability risk with this API is that it is building on a
rocky foundation. The existing session history spec does not match browsers
very well, and browsers do not match each other. Since this new API layers
on top of the existing model, this could cause issues.

We have attempted to address this via a solid and well-tested specification
for the new API, as well as ongoing efforts in whatwg/html PR #6315
 and elsewhere on the HTML
Standard issue tracker

to reform the foundational parts of the specification. For example,
although the navigation API's new events, such as currententrychange, are
fired at well-specified times, there is an existing interop problem
 regarding the timing of
popstate vs. hashchange events, which makes it difficult to write tests for
the ordering of currententrychange vs. hashchange/popstate. Working on such
existing interop issues and specification problems, and then expanding the
navigation API test suite to cover any such interactions, is our team's top
priority after this launch. See also this tracking issue
.

Regarding whether this new API will be implemented in other browsers, we
have been encouraged by the consistent and positive collaboration with
Gecko engineers, which has led to several API changes and a good amount of
review. (We have no signal from WebKit.)

Compatibility

This has been the team's main focus for the last few months, as we burned
through the list of potentially-compat-impacting issues
. In collaboration with
Gecko this led to several improvements, such as the API rename (from app
history), a change  in
how replacement navigations are requested, and the addition
 of an indicator for when
a download is requested. We believe the remaining issues (3 at the time of
writing) are manageable:


   -

   #72 : this will result
   in firing an event more often during extreme edge case scenarios involving
   replacement navigations, or in less-rare-but-still-rare scenarios involving
   the user clearing their history. Neither case should prove problematic.
   -

   #207 : the most
   likely solution will either be leaving things as they are, or changing the
   timing of an event in a way that will not disturb "normal" usage of the
   API. Although such a timing change could be risky if this API had wide
   deployment, we believe that changing the timing within a milestone or three
   would not be problematic if it ends up being desirable.
   -

   #202 : this issue is
   about the default for how focus is managed following a navigation
   API-intercepted navigation. We believe the currently-chosen default is
   probably the best, especially given testaments on that thread from the
   accessibility community and from web framework authors. However we have not
   yet closed the issue as we haven't concluded the discussion with Gecko
   engineers. Similar to #207, this would probably be changeable within a few
   milestones if necessary, without significant impact to sites using the API.
   And if we did change it, early-adopter sites could easily restore the
   previous behavior by changing the value of an option.


Signals

Gecko: No signal .
Initial positive opinions on the issue, and continued engagement on the
design, but not yet an official position.

WebKit: No signal
.