This explainer begins with a desire for web application control. It would be useful for the explainer (as for explainers in general) to trace the motivation for the feature back to an underlying need that end users of the web have; this would make the purpose of the feature clearer.

Hi,

Thanks for bringing this review to us. In addition to @dbaron's comment above, we're trying to require all requests for review to have considered the questions in our security & privacy questionnaire. Please let us know via a comment here when you've run through the security & privacy questionnaire and can share your findings with us.

So one thing the explainer says is:

Crucially, this only allows certain navigations to be intercepted. The user is still in control of the experience, so if they really want to, they can say "Open in new tab" and the app will not be allowed to prevent the page from opening. This is only used to prevent basic navigations, such as left-clicking a link.

Is "left-clicking a link" the only navigation that's intercepted? If not, what other ones are? (Are assignments to location.href? Are redirects?)

What if the user's intent when left-clicking the link was that they really wanted something in the current window? Is that intent of left-clicking really less clear than a user's intent to "Open in New Tab"? (Is it less clear only because sites have been more able to do other things with it and thus sites are already violating the user's intent?) Should we be giving users a clearer way to express the intent of "open this right here" if a left click doesn't do that?

There is a new shortcut proposal from MS: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Shortcuts/explainer.md

I think the explainer could make it a bit more clear that this will allow people to attach behavior to link navigation, for instance a right-click menu showing items like "email" which would just pop up the email dialog inside gmail and the like.

Is "left-clicking a link" the only navigation that's intercepted?

No, other navigations may also be interecepted, e.g. those triggered by registerProtocolHandler or starting a PWA via an app icon.

Should we be giving users a clearer way to express the intent of "open this right here" if a left click doesn't do that?

Yes, UAs could provide something like this. Our goal is that the user is always in control of their experience, but that developers also have more power to improve the user experience.

So I'm a little nervous about this bit:

If the launch handler does not:

i. Focus a client. ii. Open a new client. iii. Show a notification (Note: permission to show notifications is required).

then the user agent should assume that the launch handler did not handle the launch, and should continue as if there were no launch event handler.

I think in other event-based APIs things like this have tended to be handed more explicitly, i.e., with event.preventDefault() if you want to suppress the default action. Though maybe that's not the convention for service workers. (Is this at all related to ExtentableEvent?)

On the other hand, I suppose this behavior makes sense here, since it's both bad for these sorts of things to disappear without an action, and also bad for them to result in two actions.

(Also, is it related to the bit about the [[handlePending]] slot, which I can't seem to find referenced somewhere else?)

In general, with @dbaron's comments above in mind, we're pretty happy with the overall shape of this proposal.

However, we think it would make sense to have a thorough security review, as this may have unforeseen security implications around navigation and/or window management.

We're going to close this for now, but please comment here or file a new issue linking to this one if there are any substantial changes or questions you'd like us to look at in future.

(And one thing to think about in terms of security review is the sorts of attacks that can trap users in a window/tab until they do the thing the site is demanding they do (e.g., grant a permission, download and run a file, etc.)