userInitiated and onclick handlers from browser UI

[domenic]

Right now userInitiated is true specifically for:

• Users clicking on (or otherwise activating) <a href="/foo"> and friends
• Users using browser UI like the location bar, back/forward buttons, context menus, etc.

Note that it is not true for <a href="javascript:undefined" onclick="event.preventDefault(); navigation.navigate('...')">. We are explicitly trying to encourage "real" links that get intercepted via the navigate handler, not these fake links which break accessibility/crawlability/user experience such as middle-click etc. So userInitiated currently does not generically hook into all user clicks; it's specifically about hyperlink clicks and browser UI navigations.

However there's an interesting category that we aren't currently considering, which is "browser UI interactions that are mediated via event handlers". Recently we've found one example of this, which is when the user clicks on a notification: this triggers the click event in the main page, or the notificationclick event in service workers, and site authors often want to perform a navigation from within such handlers.

It seems reasonable that such navigations be considered userInitiated, but doing so would either require more subtle rules than what we have now (e.g. special casing those events??) or would require changing the definition to something like "was triggered while the relevant window had user activation". The latter would mean giving up on our technique of discouraging fake links, since clicking on those will cause user activation.

Other speculative examples of such browser-UI-driven, but handler-mediated, interactions are:

• OTP device usage, e.g. touch your security key and this fires an event which might want to navigate you to the next page in the log-in flow
• Gamepad button presses, e.g. you press the square button on your PlayStation controller which fires an event which might want to navigate you back in the history

---

This starts to get at a larger question, which is what we're really trying to accomplish with userInitiated. Who is it for? Router developers? Metrics gatherers? Not sure. Either way, I suspect it might not be the right leverage point to try to apply pressure against fake-links, and moving to a simpler user-activation definition might be a good idea...

[samthor]

Honestly, for some of those use-cases, why not let this be set by the developer? Let's say I was implementing navigation-by-controller via a JS library—it might be nice to set the boolean so that a "navigate" handler responds appropriately. (That could be paramount to removing it, since you could just say navigationInfo should specify anything interesting about the navigation, and I think you have an open bug for what that looks like in the <a href="..." case, ... although then you get into sub-protocols about standard contents of navigationInfo).

I appreciate that the boolean is potentially meant to identify "real" navigation for timing—it's something that can't be faked—but a site can just opt out completely from navigations it know might be "bad" by identifying them first and doing the JS trick anyway.