Re: [w3c/permissions] Handle non-fully-active documents (#162)

Hi @rakina, sorry for throwing you into the deep end of this API! Thanks for sticking with it! 

> I think I'm still a bit concerned if sites will break if we don't send the onchange event for the `PermissionState`, so let me try to understand how it's used. Are sites expected to call `permissions.query()` every time they want to use an API that needs permissions, or is it more common for them to query only once and listen to the onchange event to update the state?

As you suggest, they would call it once, hold the reference to say `"const perm = permissions.query(...)"`, and use rely on the events. 

> If it's the latter, I'm worried that sites might lose out on changes (especially to when they lose permission). 

Ok, so, potentially... let's work through this use case together:

 1. Page loads.
 2. Developer creates a permission object (`perm`) and registers "change" listeners.
 3. Window navigates, page gets BFCached. 
 4. In the new page, `N` permissions change ... some time passes ... back button pressed!
 5. Page comes back to life. 

So, "N Permissions" changed. For example, Geolocation was enabled, then disabled, then enabled again, etc. Other permissions changed too. 

Personally, I don't think it would make sense to queue up a bunch of events (or even the last event) at that point, as it would be confusing to deliver them. An extreme case, it would have multiple change events.  

I think the best thing to do is listen for "pageshow", and check if `event.persisted`. Then call `permissions.query()` again and check if the permissions have changed, and rewire the events.

> What would happen if the page tries to use an API without permission? Will it just throw error/never return/etc? 

Most APIs would throw/reject, which is ok IMO. But they need to do code defensively, because permissions could potentially change without notification. 

> Can that potentially be dangerous? I wonder if it might cause sites to just inexplicably break because the permission-granted-path is used instead of no-permission-path, since the site won't be aware of the change.

I don't think so (but *maybe*!). But if the code has been written defensively - which they would need to do regardless, because they might not be allowed to use the API by policy - then it should be ok. 

> I think I'm fine with rejecting if that fits the API design. I think this a problem only for iframe detach - it's not a problem for bfcache since you can't access the page while bfcached, and can't have other page refer to the page before (per whatwg/html#6858)

Exactly, yes. This may need some spec changes, but it's manageable. 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/issues/162#issuecomment-887268701