Handle non-fully-active documents

[jan-ivar]

It's possible to invoke methods on objects in windows with no longer fully-active documents, because DOM. Generally, these are edge-cases with few if any use-cases other than exploits.

While individual specs are required to think about such cases, very few do.

This presents a unique problem for APIs exposing powerful features behind permissions, because we tie permissions to realms and origins. Specifically, we have to be careful about things like showing the right requesting origin in permission prompts, something that's only guaranteed to make sense from documents that are still fully active.

As an extra safeguard, would it make sense to add prose to the request permission to use algorithm to return "denied" if the responsible document is no longer fully active?

This would expressly forbid powerful features in these edge cases. I can't think of a case where doing so would be a problem.

@jyasskin Thoughts?

[jan-ivar]

From a practical standpoint, this would give implementers an error to throw (e.g. "NotAllowedError" in gUM) in specs that haven't expressly thought about this.

[jyasskin]

I think the spec currently permits browsers to set the permission state to "denied" when a document isn't fully-active, on the theory that becoming not-fully-active is new information about the user's intent, and that has the effect of making request permission also return "denied".

It sounds like a good idea to require this instead of just allowing it. @raymeskhoury, what do you think?

[raymeskhoury]

sgtm. We might want to put this inside the section on retrieving the permission state though.

[rakina]

This thread is talking about "fully active" state changing due to the document getting detached. For that case, not allowing to query permissions seems reasonable. There's another way for the "fully active" state to change: the user navigated away and the page gets into the back/forward cache (see article, guide). When that happens, the page can't run script so querying permissions is not possible and should not be a problem.

However, there's also the "permission status change" event which I think this thread hasn't talked about, but is being updated in @marcoscaceres' PR: #249 . I'm not really sure when this will be triggered - is it possible for this to be triggered by another frame/page? If so we need to decide whether we should "drop" these changes (never send the "change" event, so when the document becomes fully active again it needs to proactively query the current state of things), or update the frame/page with the latest state when it becomes fully active again if any change has happened while it's not fully active (Note that this should update the document with the "latest status" instead of a full queue of events. See last paragraph of 2.8.2 for more details)

[marcoscaceres]

Sorry for the delay, @rakina. I've been trying to educate myself further about BFCache.

However, there's also the "permission status change" event which I think this thread hasn't talked about, but is being updated in @marcoscaceres' PR: #249 . I'm not really sure when this will be triggered - is it possible for this to be triggered by another frame/page?

It cannot be updated by another page in the context of this specification. However, the end-user could revoke a permission manually by manually changing a site's permissions' settings.

There are two cases I can think of (there may be others, and hopefully other folks will chime in!):

Case 1 - BF restore

1. Parent document creates an iframe (page1.html).
2. permission is granted for powerful feature X.
3. iframe is navigated to another page (page2.html) - page1.html is now in BFCache.
4. User revokes permission for origin for power feature X.
5. window.history.back(); gets called.
6. page1.html's document gets unfrozen from BFCache.

Now we have a situation:

1. Should the permission change event be delivered? (probably yes - this might already happen automatically, but it's hard to test as BFCache is somewhat unreliable).
2. Every API MUST recheck if it's "allowed to" use the powerful feature, like Geolocation now does (we make that clear in the TAG recommendation, if it's not already clear).

Case 2 - Reference Theft

1. Parent document creates an iframe (page1.html).
2. permission is granted for powerful feature X.
3. Parent steals a pointer to the iframe's permission instance, causing GC to no longer be possible for that instance: that is, const stolen = iframe.contentWindow.navigator.permissions; // lulz
4. iframe is navigated to another page (page2.html).
5. navigator.history.back(); gets called - new window/document gets created.
6. Parent frame calls stolen.query({name: "geolocation"}).

In this case - which has no practical application whatsoever:

• Return a promise rejected with "NotAllowed" DOMException.

UPDATE: fixed a few things above.

[marcoscaceres]

@rakina wrote:

If so we need to decide whether we should "drop" these changes (never send the "change" event, so when the document becomes fully active again it needs to proactively query the current state of things),

In case 1 above, I suggested that maybe the browser should wait and deliver the changes... but now I thinking it's not worth it (given complexity), and we should do as you eluded to: let the developer recheck the permission state themselves on "pageshow".

That keeps things simple and provides all the necessary assurances that everything is up to date with respect to any permission.

Roughly:

window.onpageshow = async ev => {
   // Did the other page change the permission from under us?
   if (ev.persisted)  {
      const permission = await navigator.permissions.query({name: "geolocation"});
      switch (permission.status) {
          // handle each case as needed... 
      }
   }
}

[marcoscaceres]

As the API only deals with querying permissions, I've updated the title of this issue to restrict the scope.

With respect to "granting permission to non-fully-active documents", that needs to be handled by the spec of each powerful feature. @rakina I'm not sure if there is wording around that in the guide, but something to consider.

[jyasskin]

@marcoscaceres This specification defines how permissions are handled in general, rather than just an API, so it's plausible for it to take a stance on whether non-fully-active documents can have permission to do anything.