Behavior of navigate(currentURL, { replace })

[domenic]

@jakearchibald, @annevk, @smaug---- and I discussed the behavior of navigation.navigate(appHistory.current.url) today.

The current spec says that this always does a replace navigation, similar to location.href = location.href. This is a bit weird because it means that the replace parameter is ignored, e.g.

// All three of these are equivalent: they all do a replace.
navigation.navigate(navigation.currentEntry.url);
navigation.navigate(navigation.currentEntry.url, { replace: true });
navigation.navigate(navigation.currentEntry.url, { replace: false });

We discussed a few options for what to do:

1. Do a same-document navigation, either push or replace according to the replace option.

   • Precedent: pushState(null, "") / replaceState(null, "")
   • But, this is not great because in general we want navigate() to be about new-document navigations; to make them same-document, you intercept with the navigate event.

2. Do a new-document replace navigation, ignoring the replace option

   • Precedent: location.href = location.href, or location.assign(location.href).
   • This is the spec's current behavior.

3. Do a new-document navigation, either push or replace according to the replace option.

   • A new-document push navigation to the same URL as the current one is only possible today by using redirects, and only in some browsers.

4. (3), but have the default be a somewhat-magic "replace for same-URL, push for different-URL". I.e.

   navigation.navigate(navigation.currentEntry.url);                      // does a replace
   navigation.navigate(navigation.currentEntry.url, { replace: true });   // does a replace
   navigation.navigate(navigation.currentEntry.url, { replace: false });  // does a push
   
   navigation.navigate(someOtherURL);                                // does a push
   navigation.navigate(someOtherURL, { replace: true });             // does a replace
   navigation.navigate(someOtherURL, { replace: false });            // does a push

5. Return a rejected promise whenever you pass replace: false and try to navigate to the current URL.

6. Return a rejected promise whenever you pass anything besides replace: true and try to navigate to the current URL. I.e. you need to be super-explicit.

We were leaning toward (4), although the lack of good precedent is a bit tricky.

[jakearchibald]

• But, this is not great because in general we want navigate() to be about new-document navigations

Is that true for appHistory.navigate('#foo')?

We were leaning toward (4), although the lack of good precedent is a bit tricky.

There's more precedent when it comes to enums, with one being "auto". I scribbled down some ideas in #113, including:

replace is currently a boolean, but it feels like it needs to be three states. So, how about entryPlacement:

• "add" - Creates a new history entry and adds it to the timeline, clearing forward history.
• "replace" - Creates a new history entry and replaces the current item in the timeline.
• "auto" - What browsers do now, where it depends on the current URL and the target URL.

[domenic]

Is that true for appHistory.navigate('#foo')?

No. The more precise statement is, we want to encourage people doing SPA navs to go through the navigate handler. Navigating to #foo is not such an SPA nav.

There's more precedent when it comes to enums

I meant precedent in regards to letting people perform same-URL push navigations. I'm not sure we want to make that functionality easy.

[domenic]

Somewhat related: whatwg/html#7386. What does appHistory.navigate("#foo") do if you're already on #foo?

[Yay295]

Scroll to #foo I'd think. That's what a link would do.

[annevk]

If that is correct and Chrome only implements the early return for Location's hash setter, I agree that ideally we would not copy that here. Typically we do not have such early returns in platform APIs (e.g., thinking of various node tree mutations).

[annevk]

What's the advantage of 4 over 2? "A bit weird" doesn't strike me as enough of a negative to introduce novel behavior.

[domenic]

Yeah, 2 is probably the path of least resistance. Maybe with a console warning, if not a rejected promise, if you pass replace: false explicitly. It feels a bit uncomfortable that the developer explicitly requested non-replace and you give them replace anyway, basically.

[annevk]

I guess I could see 5 being okay. Perhaps some input from web developers would help sway this one way or another.

[annevk]

From #72 (comment):

Currently the HTML spec has such a gadget: it makes the replace-or-push decision based on the iframe's current URL. But we should fix that separately. For example, we could adopt Chromium's solution, which is to always push when the navigation initiator is cross-origin.

This approach doesn't work with upfront decisions, right? (I.e., the idea that you decide before navigating whether you end up replacing or pushing.) Because the initial URL could be same-origin, but then redirect to the URL you want to attack.

[domenic]

The decision is made based on the initiator document's origin vs. the target iframe's current document's origin. That works, I think.

Cases:

• Initiator document is same-origin to target iframe's current document and target iframe's destination document: will be push or replace, but everything is same-origin so it's fine to expose the information
• Initiator document is same-origin to target iframe's current document but cross-origin to target iframe's destination document: the URLs are not the same so will be push anyway
• Initiator document is cross-origin to target iframe's current document but same-origin to target iframe's destination document: the URLs are not the same so will be push anyway
• Initiator document is cross-origin to target iframe's current document and cross-origin to target iframe's destination document: will always be push, per the Chromium change