Remove the title argument from registerProtocolHandler()

[annevk]

No implementation does something with it UI-wise, fortunately. Unfortunately it's still observable, so this would require implementation changes and a test to see that it's in fact ignored and not stringified.

cc @ericlaw1979 @fred-wang

• At least two implementers are interested (and none opposed):
  • Firefox
  • …
• Tests are written and can be reviewed and commented upon at:
  • HTML: remove title argument for registerProtocolHandler() web-platform-tests/wpt#22678
• Implementation bugs are filed:
  • Chrome: …
  • Firefox: …
  • Safari: …

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

---

/system-state.html ( diff )

[domenic]

@mgiuca, are you still working in this area of Chrome, or know someone who is? This is a pretty small change.

[connor-moody]

Related to this change, we at Microsoft are currently working on adding a standard for PWA protocol handlers with an associated title field (explainer here).

We envision that the title field will be useful for larger apps with multiple functions (e.g. a mail app with an email handler and a calendar handler or a messaging app that handles irc:// and sms://). At an implementation level, we plan on making the title visible both in the browser and in the OS (where possible) to make PWAs feel more like native apps to users.

While PWA protocol handlers and registerProtocolHandler() will not strictly be tied together in the web standard, including a title argument in both would provide a more unified UX between the two.

[mgiuca]

Happy to let Connor think about this in detail (their team has been working in this area of Chromium).

My high-level guidance has been to try and keep the programmatic registerProtocolHandler and the newly proposed declarative protocol_handlers as close as possible, so if they think the title is useful for one, it should maybe be kept for both.

Having said that, we do want to be careful about spoofing when we let apps set custom titles for things that aren't their main title (e.g. you install an app called "Monkey Game" and suddenly it's showing protocol handlers for "Bank of America"). That's the reason why, for Web Share Target, we only allow a single share target, and it has no explicit "title" field (so we always name the share target after the title of the application, which the user agreed to during the install prompt). I feel like the same rationale applies to protocol handlers.

We envision that the title field will be useful for larger apps with multiple functions (e.g. a mail app with an email handler and a calendar handler or a messaging app that handles irc:// and sms://). At an implementation level, we plan on making the title visible both in the browser and in the OS (where possible) to make PWAs feel more like native apps to users.

If you had such an application, say "Microsoft Outlook", would there be any reason to have separate custom titles for the irc and sms protocol handlers? Why would it be insufficient to just show the title of the application itself, "Microsoft Outlook"?

[connor-moody]

@mgiuca you bring up a valid concern about the security implications of including a title. In the spec for PWA handlers, we would want to include guidance similar to the "Misleading Titles" section of the registerProtocolHandlers standard, pointing out that implementations should always display origin along with the title.

Regarding your question about using the app name in place of custom titles - in the case you referenced, using "Microsoft Outlook" as a handler title may be sufficient. A different case where a custom title field may prove useful is if a user has installed a native app and a PWA of the same name. If user has both the native and PWA versions of "Microsoft Word" installed with no custom title, OS disambigation dialogs would confusingly prompt the user to choose between "Microsoft Word" and "Microsoft Word". If a custom title is available, a user could be prompted to choose between "Microsoft Word Classic" and "Microsoft Word Online".

Whatever the consensus on a title for registerProtocolHandler() ends up being, we hope to align PWA protocol_handlers as closely as possible to improve UX around the APIs.

[mgiuca]

Regarding those specific examples: I feel like the PWA vs native app disambiguation case is more general than protocol handlers. If you need to disambiguate the app name in the protocol handler so the user can tell the difference between two otherwise identical apps, then surely you also need to disambiguate in OS shortcuts, share targets, store listings, etc... anywhere the app title is displayed. So again, I feel like this isn't a use case for having a protocol handler with a different title to its app title.

[connor-moody]

Good point, it seems like a custom title field would add complexity without significant value. We will remove the title field from our protocol_handlers proposal, which means that the removal of the title argument from registerProtocolHandler() can continue as planned.

[fred-wang]

So it seems there is consensus to remove the title argument, right? What is missing before merging this PR? On the implementation side, Igalia is happy to send patches / intent-to to Firefox / Chromium.

@annevk Probably the comment aligning PWA's protocol_handlers and registerProtocolHandler, also applies to extensions' protocol_handlers ( https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers )? I assume we want to remove (or at least deprecate) "name" and rename the keyword (or at least add a new one and deprecate current one) uriTemplate => url?

[annevk]

Maybe, extensions have a different threat model to some extent and are someone outside the realm of web standards.

What's missing is implementation bugs as it does seem like we have buy-in from Chrome/Firefox.

[fred-wang]

Maybe, extensions have a different threat model to some extent and are someone outside the realm of web standards.

OK, I guess "name" is not relying on registerProtocolHandler()'s title support anyway, so it seems fine to drop the latter.

What's missing is implementation bugs as it does seem like we have buy-in from Chrome/Firefox.

I'll open those bugs. Was not sure whether that was needed or if a "lgtm" from Chrome/Firefox was enough here.

[annevk]

Per https://whatwg.org/working-mode#changes we'd like to have explicit bugs on file (linked from here). This helps future readers and ensures everyone has been informed of the change.

[fred-wang]

  * Chrome: …
  * Firefox: …
  * Safari: …

I filed bugs for Chromium and Mozilla:
https://bugs.chromium.org/p/chromium/issues/detail?id=1072461
https://bugzilla.mozilla.org/show_bug.cgi?id=1631464

WebKit does not support registerProtocolHandler() so not sure whether it makes sense to open a bug to remove the title argument.

[annevk]

Thanks all!