Comments (6)
2 seperate permissions. The dialog is a UA issue and not spec detail.
Ideally the UA would be able to combine them since the calls are async. I imagine a pattern where the UA waits a turn of the event loop for the web-app to enumerate all its permission requests, then shows the dialog might work well. Some of the current permission request APIs (geoloc, Notification) are not Promise based, but imagine this.
Promise.all([
Notification.requestPermission(), // Some shimmed form that returns a Promise
navigator.push.hasPermission()
]).then(function(perms) {
if (perms[0] == 'granted') { // notifications ok; }
if (perms[1] == 'granted') { navigator.push.register(); }
});
from push-api.
@nikhilm Have you been experimenting with the idea further?
There's related discussion over at SysApps (http://lists.w3.org/Archives/Public/public-sysapps/2014Apr/0070.html), and the group is pondering whether to draft an API that would formalize the pattern, to be implemented by APIs that request permissions. Something along the lines of:
enum PermissionLevel {
"default",
"denied",
"granted"
};
[NoInterfaceObject]
interface Permissions {
Promise<PermissionLevel> requestPermission ();
Promise<boolean> hasPermission ();
/* ... */
};
Notification implements Permissions;
PushManager implements Permissions;
/* ... */
Geolocation implements Permissions;
WDYT?
from push-api.
The solutions proposed by @anssiko or the Promise based one @nikhilm outlined sound very workable. Is that even conceivably implementable in the same time-frame though?
If it's not and one permission didn't imply the other, "push" and "notifications" would essentially be split along "spec lines" that would greatly limit the functionality that already exists in the marketplace as a single unit.
It's like if "push notifications" also required a network permission to operate (clearly not in the same spec, but also clearly required).
from push-api.
I haven't thought about this at all :) I'm not a spec guy, this was just what I came up with off the top of my head.
from push-api.
@nikhilm I meant have you experimented with the idea in implementations (or have plans to)? Personally I feel this is a good proposal that would benefit from further experimentation in code.
As you probably know, the wider web community is currently looking at the permission solution space, and I feel this is good input to that discussion. I especially like the way how this could be retrofitted to many existing APIs without breaking backwards-compatibility. It would be too early to spec this feature yet though, we'd need feedback from implementers first.
Do you envision the Promise returned by requestPermission() to resolve with boolean (to indicate whether the request was granted or not), permission level of some sort (e.g. "default", "denied", "granted"), or something else? I updated the IDL sketch above to reflect the latter alternative.
from push-api.
I was pointed to this GH issue by Dave Raggett. I realise that you were sketching something close to what I proposed in public-webapps yesterday: http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0389.html
Note that we are not including requestPermission() in this proposal (contrary to what was sketched here) and we decided to go for a single entry point API instead of a pattern. There are also slight differences, including the ability to specify options when checking for a permission.
from push-api.
Related Issues (20)
- PushPermissionState and PermissionState are the same
- Progressing spec to CR HOT 4
- Should there be a UTF-8 health warning? HOT 2
- Status report and planning for TPAC 2021 HOT 1
- Consider using DOMHighResTimestamp instead of DOMTimeStamp HOT 1
- Mention or enforce userVisibleOnly check in PushManager.subscribe? HOT 2
- Clarify purpose expirationTime HOT 1
- Duplicate definition of PushPermissionDescriptor HOT 1
- Should push be a policy-controlled feature? HOT 1
- Does PushManager subscribe() need transient activation check? HOT 2
- Question: what about shared device
- TPAC 2022 status report
- Documentation: It's not clear how to specify the push service HOT 2
- Browser MUST always display a permission prompt after a user interaction HOT 2
- New push subscription MUST have an endpoint that's different from the original HOT 1
- Best practices to dismiss web push notifications cross devices HOT 1
- Declarative Web Push HOT 14
- Permission Revocation - English language clarification
- Mention Safari Implementation HOT 1
- WPT testability HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from push-api.