Declarative Link Capturing: Discuss use of existing_client_navigate with URL fragment changes

[mgiuca]

In the DLC proposal, we have the following modes (among others):

• existing_client_navigate (ECN), which navigates an existing client to a new URL, and
• existing_client_event (ECE), which fires an event at an existing client, expecting it to do whatever is needed inside the JavaScript context to respond to being launched.

We've always thought of ECN as being the "bad one" that you "probably shouldn't use", because even though it's nice and simple to spec and implement, it will potentially cause data loss, as it forcibly navigates an existing client (even though I would assume we'd show the onbeforeunload dialog, that is somewhat unreliable as a means of preventing data loss, and also a bad user experience).

And we've thought of ECE as the "ideal one" but that's difficult to spec and implement, for both us and the site, and also will likely require more bikeshedding as the API is not obvious.

However, @raymeskhoury pointed out that if you have a site where all the URLs share the same host/path/query and just vary by fragment (or hash), then ECN essentially acts like ECE. It doesn't cause a page navigation, it just changes the URL and fires an onhashchange event, which you can then respond to however you like.

Which is clever. It's not quite a replacement for ECE, since it may interfere with sites URL fragment setup, and also doesn't allow you to pass lots of data to the client (e.g., Web Share Target or File Handlers), but it should do for most cases. It might be a bit of a hack though, if your URL is going to be # all the time and you're just using this as a way of passing messages into the app (e.g., every time ECN navigates to #some-docid, your onhashchange reads it, actions it, and then sets the URL back to #).

The "non hacky" way to use this would be if you have a legitimate URL scheme where resources within the app are identified by #some-docid fragment URLs. ECN changes the URL to #some-docid, the onhashchange handler modifies the page state to match, and leaves it at that URL, so the URL accurately reflects the current page state.

We should write about this in the explainer, and use it to inform the design of ECN vs ECE, and perhaps even consider dropping ECE if all of its use cases are met with the above technique.

[fallaciousreasoning]

However, @raymeskhoury pointed out that if you have a site where all the URLs share the same host/path/query and just vary by fragment (or hash), then ECN essentially acts like ECE. It doesn't cause a page navigation, it just changes the URL and fires an onhashchange event, which you can then respond to however you like.

Interesting, that is pretty clever. I wonder if we could extend it to work with path/queries too. We already have history.pushState and history.popState, but I don't think we have an equivalent of onhashchange for these changes (judging by this SO question and my own experiences).

This does seem quite elegant. Maybe the path of least resistance would be speccing an 'onlocationchange' event?

[alancutter]

Note: existing_client_event has bike-shedded into client_mode: focus-existing.

I don't think we're going to drop the ability to not navigate an existing window, doing so would force sites to rearchitect themselves to use a URL fragment scheme.