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
  • Gecko
• Tests are written and can be reviewed and commented upon at:
  • IDL will be tested, but otherwise there's no good infrastructure for this as-of-yet.
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/382298314
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1935325
  • WebKit: N/A
• MDN issue is filed: Document Declarative Web Push mdn/content#36464
• 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.

[annevk]

That seems a little premature? We could always overload once we establish we need the complexity, no? "Baby steps" and all that.

[saschanaz]

If we are going to only ship one extra member, sure. I wonder we should make the tab selection optional if we are going to do an implementation detailed magic there though.

[saschanaz]

Now I'm confused, I was assuming that the new intention is to reuse the existing tabs, and the full URL comparison was accidental. It seems the intention is actually to reuse only if the URL is exactly the same of one of the existing tabs and open new tab for anything else. Not sure how that's strictly useful than just open new tab for everything for V1, given a lot of existing use cases assign a new URL for each notification because a notification frequently means there's a new content (e.g. Mastodon, Twitter, YouTube, Slack, Instagram, etc.. Chat apps may have higher frequency of having same URL but still with severely limited chance.)

[annevk]

The full URL comparison is not accidental. On all Apple platforms, when you click a link outside the default browser (or run open https://github.com/whatwg/notifications/pull/213), it'll open the default browser, and if that browser is Safari, it'll navigate an existing tab with that URL.

That seems like reasonable behavior for external links as part of v1 of this feature, but as other behavior is reasonable too and this is really the realm of user interfaces, the PR doesn't require an exact behavior, just that a navigation occurs.

As we get more adoption and feature requests around this, we can certainly add some enhancements to this, such as your proposed click event, but none of that seems necessary to us for v1.

[annevk]

@saschanaz let me reproduce your comment here since you commented on a resolved thread without reopening it:

I'm still not convinced why the specced behavior is useful. It looks either not useful as websites with permalinks will always get new tabs, or surprising as websites without permalinks navigate within existing tab unexpectedly.

Given Apple shipped the feature, maybe you can share the idea why Apple decided this way or proof that this doesn't cause footgun.

The behavior we ship aligns with how links from elsewhere in the OS cause the browser to navigate today. It's what end users already expect and has not resulted in any issues with early adopters to our knowledge. I think it would also be fine to leave this implementation-defined for now and potentially give web developers more control over the exact behavior down the line.

[saschanaz]

since you commented on a resolved thread without reopening it:

I couldn't reopen it, the unresolve button doesn't work for me, sorry. And I did not resolve it, so I wonder you can?

The behavior we ship aligns with how links from elsewhere in the OS cause the browser to navigate today.

AH. AAH. I was confused about this statement while sitting in front of a Windows machine and then started thinking maybe this is macOS convention. And boom, that's true, if I click links on Mail app with the Safari as the default browser, then it works just as you described.

But given Edge doesn't do that on Windows for example, I don't think we can apply that to every platform. So maybe we can allow always opening a new tab in a spec level, per the platform convention?

[annevk]

Okay, I've gone back to the initial version of giving implementations more freedom and added encouragement to match platform conventions.

[saschanaz]

LGTM with some nonblocking comments.

[saschanaz]

But does Safari actually focus-and-navigate a tab? I think it just focuses a tab and does not navigate per what I see for the non-push external clicks. But I may be wrong.

Also does this need to say about focusing?

[annevk]

It definitely navigates for me when I follow a link from a different app or run open https://github.com/whatwg/notifications/pull/213. Just lost my initial comment trying that.