Define permission lifetimes - #287
Conversation
|
Woohoo, thanks for specifying this :-) That's it, that's the comment. |
There was a problem hiding this comment.
LGTM, just a couple of editorial notes.
|
Thanks @tomayac! It's a start 🙏 Any further feedback you can provide is always welcome! You always provide great feedback. |
Co-authored-by: Jeffrey Yasskin <jyasskin@chromium.org>
7e595a4 to
fea3971
Compare
There was a problem hiding this comment.
Thanks, I think this works for integrating the lifetime into the algorithms.
| </p> | ||
| <p> | ||
| When the permission [=permission/lifetime=] expires for an origin, and if there are | ||
| [=browsing contexts=] present pertaining to the [=permission=]'s associated origin, |
There was a problem hiding this comment.
Does "pertaining to" have a precise definition?
There was a problem hiding this comment.
No... I was hesitant to use that word. I'm open to suggestions as to how to make that association (I'll give that some further thought too).
There was a problem hiding this comment.
I think we're trying to say, if you're the top-level browsing context for a given origin and have any ancestor browsing contexts, revoke permission for all browsing contexts? I guess https://html.spec.whatwg.org/#nested-browsing-contexts gives you most of what you need.
There was a problem hiding this comment.
It should be possible to treat it like a map, in that we can just grab all any/all browsing contexts associated with an origin (not really worrying if they are nested or not.)
| <p> | ||
| When the permission [=permission/lifetime=] expires for an origin, and if there are | ||
| [=browsing contexts=] present pertaining to the [=permission=]'s associated origin, | ||
| the user agent MUST run the [=powerful feature/permission revocation algorithm=]. |
There was a problem hiding this comment.
Run it where? "Queue a task to run the algorithm on each browsing context's event loop"?
There was a problem hiding this comment.
Yeah, something like that could work... will add it.
BTW: I think we need to relook at the "permission revocation algorithm"... it seems to call it self recursively.
| [=browsing contexts=] present pertaining to the [=permission=]'s associated origin, | ||
| the user agent MUST run the [=powerful feature/permission revocation algorithm=]. | ||
| Alternatively, if there is no [=browsing contexts=] present, the user agent MUST | ||
| revoke a permission for the origin by setting it back to its default [=permission |
There was a problem hiding this comment.
"Setting" a permission state isn't really defined in this spec, in order to give UAs lots of freedom of how to infer what the user wants. I think it's clear enough what you mean here, but it could help to define "setting a descriptor's permission state to X" as something like "as if the UA had returned X when reading the descriptor's permission state for some group of settings objects".
There was a problem hiding this comment.
"Setting" a permission state isn't really defined in this spec, in order to give UAs lots of freedom of how to infer what the user wants.
I think that's fine, but conceptually there is still some datastore somewhere that gets updated (that is, a permission is bound to an origin or a realm or whatever). When the update happens, it gets asynchronously propagated.
I think it's clear enough what you mean here, but it could help to define "setting a descriptor's permission state to X" as something like "as if the UA had returned X when reading the descriptor's permission state for some group of settings objects".
Upon reflection, I think we should do this as a followup, because it gets into the problem above about conceptualizing how permissions are actually stored (or how we will pretend they are stored for the purpose of the specification).
Co-authored-by: Jeffrey Yasskin <jyasskin@chromium.org>
| </p> | ||
| <p> | ||
| When the permission [=permission/lifetime=] expires for an origin, and if there are | ||
| [=browsing contexts=] present pertaining to the [=permission=]'s associated origin, |
There was a problem hiding this comment.
I think we're trying to say, if you're the top-level browsing context for a given origin and have any ancestor browsing contexts, revoke permission for all browsing contexts? I guess https://html.spec.whatwg.org/#nested-browsing-contexts gives you most of what you need.
|
I’m going ahead and merging this as it gives us a good foundation to go off (and it’s blocking geo). |
SHA: 8bf9509 Reason: push, by @marcoscaceres Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
closes #233
Exports [=permission/lifetimes=].
Preview | Diff