Intent to Prototype: Permission automation for registerProtocolHandler

[Javier Fernandez]

Contact emails

jfern...@igalia.com

Explainer

https://github.com/Igalia/explainers/blob/main/custom-protocol-handlers/Permission-API/README.md

Specification

https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers

Summary

Provides Automated testing support for the registerProtocolHandler method, so that we could avoid the user prompt dialog to grant permission for the protocol handler registration. We would need to define a new 'PermissionName' that we can use as part of the 'PermissionDescriptor' argument for the SetPermission command provided by the WebDriver API.

Blink component

Blink>HTML>CustomHandlers

Motivation

Currently there are only manual tests in the WPT repository to cover the registerProtocolHandler functionality. The main challenges to implement automated testing are: * UserActivation: The registerProtocolHandler method requires transient activation to consider the request; otherwise it'll be ignored. * Permission prompt dialog: Although the spec is quite vague on this regard, current implementations (Firefox and Chrome) requires the user to grant permissions for the handler registration. Using the test_driver.set_permission function we could make tests like this way: promise_setup(async () => { await test_driver.set_permission({name: 'protocol-handler'}, 'granted'); await test_driver.bless('handler registration'); // Provides UserActivation register(); });

Initial public proposal

https://github.com/whatwg/html/issues/7920

TAG review

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

No

Debuggability

Is this feature fully tested by web-platform-tests?

No

Flag name

Requires code in //chrome?

True

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1321073

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5047679389270016

[Rick Byers]

Cool! Thank you for making more of the platform testable in WPT!

Has there been any discussion in the HTML spec community of making registerProtocolHandler an official "powerful feature"? Will doing so also have web visible implications via permissions policy?

Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1ce0bb72-2b95-4e9a-f9bc-f1e156682811%40igalia.com.

[Javier Fernandez]

Hi Rick,

On 13/5/22 16:21, Rick Byers wrote:

Cool! Thank you for making more of the platform testable in WPT!

Has there been any discussion in the HTML spec community of making registerProtocolHandler an official "powerful feature"? Will doing so also have web visible implications via permissions policy?

I've just started the discussion, both at the level of WPT [1] and in the html spec [2], but still not much feedback.

Honestly, I've started this journey just trying to improve the feature's testing, but the issue has growth so that we have now the opportunity to evolve the registerProtocolHandler feature itself. In any case, I think the goal is worth the effort, so that's why I've sent the intent. 

IMHO, with the "powerfull feature" definition in mind "is a web platform feature (usually an API) for which a user gives express permission before the feature can be used"  the registerProtocolHandler should be considered as such. I'd really like to get feedback from people with more experience, but I really think user must grant permissions in all the cases before registering any protocol handler. Currently, the spec is a bit vague [3] on this regard, so I think we can improve a bit:

"User agents may, within the constraints described, do whatever they like. A user agent could, for instance, prompt the user and offer the user the opportunity to add the site to a shortlist of handlers, or make the handlers their default, or cancel the request. User agents could also silently collect the information, providing it only when relevant to the user."

I have to say that, for the time being, the intent is only for the Automated testing capabilities. It's not in my plans to implement the "request permission" [4] functionality. Currently in chrome we do have a PROTOCOL_HANDLER setting but we don't store any data; the requestProtocolHandler method just launch a prompt dialog to ask the user for permissions to proceed or not with the registration. I don't have plans to change that, for now.

Regarding permissions policy, I admit I haven't considered it and I don't have experience with that spec, but now that you mention I guess it'd made sense to implement a permission policy for the Custom Handlers feature.

--
javi

[1] https://github.com/web-platform-tests/wpt/issues/26819
[2] https://github.com/whatwg/html/issues/7920
[3] https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
[4] https://www.w3.org/TR/permissions/#requesting-more-permission

[Rick Byers]

On Fri, May 13, 2022 at 11:17 AM Javier Fernandez <jfern...@igalia.com> wrote:

Hi Rick,

On 13/5/22 16:21, Rick Byers wrote:

Cool! Thank you for making more of the platform testable in WPT!

Has there been any discussion in the HTML spec community of making registerProtocolHandler an official "powerful feature"? Will doing so also have web visible implications via permissions policy?

I've just started the discussion, both at the level of WPT [1] and in the html spec [2], but still not much feedback.

Honestly, I've started this journey just trying to improve the feature's testing, but the issue has growth so that we have now the opportunity to evolve the registerProtocolHandler feature itself. In any case, I think the goal is worth the effort, so that's why I've sent the intent. 

IMHO, with the "powerfull feature" definition in mind "is a web platform feature (usually an API) for which a user gives express permission before the feature can be used"  the registerProtocolHandler should be considered as such. I'd really like to get feedback from people with more experience, but I really think user must grant permissions in all the cases before registering any protocol handler. Currently, the spec is a bit vague [3] on this regard, so I think we can improve a bit:

"User agents may, within the constraints described, do whatever they like. A user agent could, for instance, prompt the user and offer the user the opportunity to add the site to a shortlist of handlers, or make the handlers their default, or cancel the request. User agents could also silently collect the information, providing it only when relevant to the user."

I have to say that, for the time being, the intent is only for the Automated testing capabilities. It's not in my plans to implement the "request permission" [4] functionality. Currently in chrome we do have a PROTOCOL_HANDLER setting but we don't store any data; the requestProtocolHandler method just launch a prompt dialog to ask the user for permissions to proceed or not with the registration. I don't have plans to change that, for now.

Regarding permissions policy, I admit I haven't considered it and I don't have experience with that spec, but now that you mention I guess it'd made sense to implement a permission policy for the Custom Handlers feature.

Thanks, that all makes sense! If it's ultimately just a webdriver change, then I'm not sure if an 'intent to ship' is even necessary. @Philip Jägenstedt would know.

And certainly I didn't mean to imply that you should integrate with permission policy etc., I was just trying to understand the scope of the web platform exposure. I can see how this may or may not really match what we normally think of as 'permissions'. @Ian Clelland could probably advise. Even if integration with the 'powerful feature' definition is the "right" thing to do, it may not be worth the effort to do it when the most important thing is just getting some automated test coverage...