This is the embargo feature where we automatically block permission requests if the user dismisses the prompt 3 times in a row.

+patricialor, how complicated would it be to add embargo to the site settings pages on desktop? It should be fairly straightforward (if it hasn't been done already?)

Hmm - in the longer term we want to hide away exceptions more than they are now. 

Adding them to the list would potentially be a bit tricky because they're a bit different from other types of exceptions. I wonder if we just want to work on hiding away the "exceptions" view more?

Currently, this exception is registered and it is a problem that you can not reset this flag, especially when you are a developer. Personally, I do not know how to reset this flag for the domain name I'm working on, maybe somebody know and could tell me how before i try uninstalling Chrome :) Regards

RE #c1, yes I think it's easy to do - SiteSettingsHelper probably just needs a general cleanup that changes everything to read from PermissionManager instead of directly off of HostContentSettingsMap.

RE #c2, what do you mean by hiding the exceptions view more? I think it's pretty hidden already?

RE #c3, you should be able to change it by clicking the lock or info icon adjacent to the URL / omnibox, and using the combobox / drop-down there to change it.

> RE #c1, yes I think it's easy to do 

The problem here is that what we list in the exceptions view is very different from what we list in Site Details or Page Info. We list the things that feed into the value determined by PermissionManager, e.g. user exceptions, enterprise exceptions, etc. We don't actually want to change it to use PermissionManager. We could potentially add extra entries for embargo, but that feels a bit weird to me because they're automatically generated by Chrome.

> RE #c2, what do you mean by hiding the exceptions view more? I think it's pretty hidden already?

The goal is that the main way to manipulate things is in an origin-centric view. Right now if you try to manipulate content settings through chrome:settings you will get a pattern-centric view. We want pattern-based exceptions to be hidden away for users who really need them. Exactly what that looks like may depend on "All Sites".

Assigning this one to dominickn, feel free to reassign it if that's incorrect.

One thing we could do here is incorporate the embargo value into the user's setting for the site. We would then need text to say that it's automatically blocked by Chrome....

But before we do that I think it would be good to know the direction we're heading in with All Sites and thinking about how we will display exceptions, etc.

Issue 796098 has been merged into this issue.

I got hit by this today; the UX here has degraded a bit over time.

https://www.chromestatus.com/features/6443143280984064 and the console notification note that "This can be reset in Page Info which can be accessed by clicking the lock icon next to the URL." This isn't true when the permission is being used from a cross-origin subframe, as there's no "Location" setting shown in Page Info, and even clicking "Site Settings" on the PageInfo does not show the permissions for the correct origin.

What's more, the Permission Indicator icon incorrectly asserts that the block will be cleared upon reload of the page, which is not accurate.

Deleted: IncorrectNotice.png 17.7 KB

	IncorrectNotice.png 17.7 KB View Download

c#10: handling permissions in cross-origin iframes has always been challenging. These issues will be solved when Permission Delegation via Feature Policy launches. Then, permissions will only be requested by top level frames, and delegated to subframes. Both page info and page actions will behave appropriately in that instance.

https://www.chromestatus.com/features/6443143280984064

as mentioned in the above link block for web developer while testing can be removed by clearing the browser data doesnt seems to be working.

This now impacts the hangouts extension for which there is less of a solution because there is no lock icon visible (see issue 913389). engedy@ can we prioritise some kind of fix for this? Happy to discuss more.