-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Remove requestPermission() #246
Comments
Relevant reading: w3c/permissions#83 |
Pull request at rsolomakhin#1. |
I'm not 100% on this being an "anti-pattern". There's a delicate balance between declarative registration (let the user agent ask when to prompt the user) and programmatic. For what it's worth, I think we will be going this way on the other handler types:
On the other hand, we tried this model with web app installation (the user agent can determine when to show an install prompt) and developers really did not like it. We have been moving ever closer to a programmatic API (BeforeInstallPromptEvent.prompt) where the developer chooses when to show the prompt. So, maybe we should not so hastily remove requestPermission. Instead, it could be taken like registerProtocolHandler as a silent background registration that does not explicitly prompt the user. |
+1 removing BTW, |
|
@mgiuca: |
OK makes sense. |
Hi @rsolomakhin, I am hearing that user consent is still required (for 'something') but the timing might vary by implementation. Indeed, within a single implementation there might be different timings (e.g., "register now on this button click" v. "just-in-time registration"). Does that sound like what you intend? If so, I think we should augment the Security and Privacy Considerations to say so. Ian |
I have concerns around Setting a permission when registration of a payment handler occurs would be appropriate tho (i.e., not one of its instruments), however. We may need to perhaps mirror what Web Share Target is doing, or reach out to a few other folks for ideas on how best to do this (I've not given it a lot of thought and I'm somewhat struggling to come up with some precedence for "register SW X to handle Y"). |
@marcoscaceres: Isn't installing a Payment Handler equivalent to an |
@marcoscaceres: I've addressed your comments on the pull request and explcitly called out that a Payment Handler is considered installed after the first call to Note that requesting user consent for an action during the action is something that permissions team considers best practice. The |
This patch is an initial implementation of the following spec change: - w3c/payment-handler#246 - https://chromium-review.googlesource.com/c/chromium/src/+/533193 This feature is still behind runtime flag. Bug: 665949 Change-Id: Ied225b89c7aed3a39955e49e9af2e4e3866a92c2 Reviewed-on: https://chromium-review.googlesource.com/914661 Reviewed-by: Jochen Eisinger <jochen@chromium.org> Reviewed-by: Raymes Khoury <raymes@chromium.org> Reviewed-by: Rouslan Solomakhin <rouslan@chromium.org> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Commit-Queue: Jinho Bang <jinho.bang@samsung.com> Cr-Commit-Position: refs/heads/master@{#539499}
According to the permissions team (@raymeskhoury, @mgiuca)
.requestPermission()
style API is an anti-pattern and users generally do not understand permission prompts that may be lacking context. I would like to send a pull-request for removing.requestPermission()
and recommending browsers to show a prompt when they deem necessary. The exact amount of specification will be hashed out between the implementers. In case of Chrome, we will show a permission prompt only when the website callsServiceWorkerREgisgration.paymentManager.instruments.set(key, data)
for the first time, i.e., theinstruments
have never been set for this site. Chrome will require a user gesture for the first-time call toinstruments.set(key, data)
. We will also look into using site engagement, safe browsing database, and certificate validity to outright rejectinstruments.set(key, data)
withNotAllowedError
without showing any prompt at all. I would love to hear feedback from the interested parties, in particular @romandev and @marcoscaceres .cc: @DurgaTheHutt, @gogerald, @anthonyvd
The text was updated successfully, but these errors were encountered: