+++ This bug was initially created as a clone of Bug #1206232 +++ Bug 1206232 will implement "temporarily blocked" permissions to protect users from permission spamming by preventing the whole tab from showing permission requests until reload, independent of whether the first or subsequent permission requests came from the top-level document or iframes. Permanently blocked permissions don't have that ability. They probably should.

After pondering this I think we should simply permanently block the top-level URI as well whenever a subframe is permanently blocked. In addition we should also adapt SitePermissions.get() to check the current URI of the passed browser document and deny if subframes have been blocked. It's very likely the user just does not want to be annoyed/never wants to give permission to the website they are seeing right now, independent of the concept of iframes. This also has the advantage of giving the user full visual feedback in the identity block and once bug 1224453 is fixed the user will have granular control over whether we correctly blocked the whole page or if they just want the iframe gone. Thoughts?

> In addition we should also adapt SitePermissions.get() to check the current URI of the passed browser document and deny if subframes have been blocked. That was supposed to read: In addition we should also adapt SitePermissions.get() to check the current URI of the passed browser and deny subframes if the top level is blocked.

This alone doesn't solve the issue that was brought up with a temporary block on the tab, which is that clicking the "X" in the Control Center won't restore the ability for the subframe to request the permission again, which can look more buggy than not showing anything at all. Maybe we should just go ahead and implement permissions for subframes in the Control Center, thus fixing bug 1224453. It might be simpler than the workarounds. Alternatively, to go with your proposed workaround, what if we also reset all permanently blocked permissions in subframes when the "X" near a permanently blocked permission is clicked? This still won't allow a permission to be restored if the same subframe is embedded in a domain that is different from the one where the permission was blocked originally, but it would mitigate the initial concern to an extent. I think the side-effect of unblocking other subframes would be a minor concern, because they can be blocked again as soon as they ask for permission.

(In reply to :Paolo Amadini from comment #3) > This alone doesn't solve the issue that was brought up with a temporary > block on the tab, which is that clicking the "X" in the Control Center won't > restore the ability for the subframe to request the permission again, which > can look more buggy than not showing anything at all. > > Maybe we should just go ahead and implement permissions for subframes in the > Control Center, thus fixing bug 1224453. It might be simpler than the > workarounds. Yes, that's what I was referring to. I'm assuming that bug gets fixed around the same time as this one. Maybe I should set that one to block this one again, to make that clear. Your concern is absolutely valid and we should take care of it. > > Alternatively, to go with your proposed workaround, what if we also reset > all permanently blocked permissions in subframes when the "X" near a > permanently blocked permission is clicked? This still won't allow a > permission to be restored if the same subframe is embedded in a domain that > is different from the one where the permission was blocked originally, but > it would mitigate the initial concern to an extent. I think the side-effect > of unblocking other subframes would be a minor concern, because they can be > blocked again as soon as they ask for permission. It's a possibility, but I'd personally prefer just having a subframe permission UI.

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information