Allow notifications and actions to specify a navigable URL

[annevk]

This makes notifications more declarative by not requiring explicit handling of the clicks by the web application.

---

This change is part of a larger Declarative Web Push effort, but can hopefully land in isolation as a small incremental step toward that goal.

• At least two implementers are interested (and none opposed):
  • WebKit
  • …
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

@saschanaz @beverloo thoughts?

[saschanaz]

1 or 2 minor changes are fine but getting more starts to be annoying, especially if we get multiple review rounds... 😛

Should we also fold in some part of #204 here? Non-persistent notification with a URL certainly has a valid action to do even if the page is closed.

[saschanaz]

(Interesting that we are currently not telling what action is invoked for non-persistent notifications, per the existing steps)

[saschanaz]

A parallel question, is WebKit going to implement actions?

[annevk]

• The couple nits have now landed separately (along with some other nits) and I rebased this.
• I'd prefer fixing Should a non-persistent notification be auto-closed or not? #204 separately. I don't really have an opinion on how that should work.
• WebKit is interested in notification actions.

[saschanaz]

Some extra questions:

1. Should we still give a chance for the webpage to handle this, so that existing active tab can e.g. open notification inbox without opening a new tab? Doing that might be a bit tricky though:

   1. Tab A triggers a notification with URL
   2. Tab A goes away
   3. User opens tab B and C
   4. User clicks notification
   5. Now which tab should respond? 🤷‍♀️

   cc @smaug----

2. We silently ignore URL parsing error here (probably for consistency with other fields), but should we throw explicitly for this one? Clicking notification with incorrect URL wouldn't open anything, and such thing probably should fail early without being shown.

[annevk]

1. We could potentially offer that in a future version, but I don't think we need to for v1. Let's see how much adoption there will be for Declarative Web Push first.
2. Hmm, per 0f8a7b6 it seems historically we didn't really define what happened on failure and just copy-and-pasted our way forward from there (with "minor" changes along the way such as adopting the WHATWG URL parser). I suppose we could start breaking with that precedent now and start throwing for new URL members. Not sure I lean particularly strongly either way.

[smaug----]

Having a way to bound to a tab might affect the API usage quite a bit. Needing to open a tab all the time even if the site was already open would be a bit annoying.

But perhaps you've had some other types of use cases in mind. In which way do you imagine one to use only the URL + new top level navigable?

[annevk]

This feature is part of w3c/push-api#360 to enable fully declarative push notifications. Perhaps it should not be allowed for new Notification(), but it also seemed kinda harmless. And perhaps we should also offer a variant that ends up navigating an existing tab instead, if any, but that seems quite a bit more involved.

cc @beidson

[saschanaz]

We should probably also consider not always opening a new tab for declarative push, btw.

[annevk]

Yeah we'll think about it and are of course also happy to consider concrete proposals. I suspect that anything we decide to do can easily go on top of this, so I'm not sure I'd consider it blocking.

[annevk]

Brady pointed out to me that we already reuse an existing tab if there is one. I don't think HTML has a good primitive for that, but I'll see about adjusting the wording to allow for that. Thanks for pointing it out! (I guess that raises the question as to whether there should be a feature to force a new window, but that's probably best deferred.)

[saschanaz]

Hmmmm, in that case I would be interested to learn more about the tab selection algorithm.

[beverloo]

Hey Anne, this seems good to us. I've two thoughts -

1. I don't love the url property name, but I can't really come up with anything much better either. Using either navigationUrl or activationUrl is much longer, and inconsistent with other properties on the notification objects.
2. +1 to @saschanaz that some sort of "how to open this" policy is necessary. We see three categories, (1) always open a new tab, (2) re-use an existing tab, and (3) re-use an existing tab unless it's been modified, e.g. dirty form fields.

Perhaps navigationUrl is an option to consider as it would work with navigationPolicy, which then could then be an enum of sorts. Doesn't have to be for this PR either, and developer feedback might highlight additional options to consider.

[beverloo]

Also - we don't have good metrics on use between Clients.openWindow() and WindowClient.navigate() (or WindowClient.focus()) unfortunately, which I can reintroduce but it'll be a while before we have data.

[annevk]

I think the policy we end up using in Safari is roughly reuse a tab with the same URL. There's a number of corner cases to imagine where such a vague notion could fall apart, but I'm also not sure we should try to nail it down in detail as I think we want this to be a little flexible to allow changes to it in the future and also because it fundamentally is also part of the overall end user experience.

I could see renaming url to navigate so it's analogous with the Navigation API. @domenic thoughts?

(Also, thanks a lot for sharing your thoughts Peter, much appreciated! And I hope all is well.)

[domenic]

I could see renaming url to navigate so it's analogous with the Navigation API. @domenic thoughts?

No strong feelings, but that (or navigationURL) seems reasonable.

For the internal slot, it does seem that something more specific than "URL" would be helpful for clarity.