finnur@, based on our conversation yesterday you might not be the right person to look at this but still assigning for triage :)

I seem to recall a UI proposal that allowed the user to press an X next to a permission setting to reset just that permission but it was never implemented. Having said that, we don't seem to retain permissions that is set to the default value, so flipping the permission value should be enough to get rid of it.

My involvement in this project was at the request of the team that Elisabeth Morant was PM for, but and Emily is. Assigning to Emily for triaging.

Change type to "Feature", since it is not regression on existing functionalities.

Assign to UI>Browser>Permissions>Prompts triage owner dominickn@.
Please feel free to re-assign. 

-Prompts, since this is in site settings.

What is the particular use case for wanting to set individual permissions to the default state on Android? We are much more constrained in terms of UI space on Android so adding more options is a tough tradeoff.

The use case I have in mind is that a user "mutes" a site by adding an exception to the sound site setting (for example, they hate the site they are on autoplays video). Later on, they want to watch a video on that site, so they want to unmute. The only way to do that on mobile is to clear site data. They should be able to go and simply remove the exception.

 

c#6: in that case, can't they simply tap the permission and set it to allowed in site settings? I checked and that seems to work.

Yep, but the issue is that that just changes the exception to an "allow" exception instead of a "block" exception. There seems to be no way to just clear it back to default. One possible solution is to change it so when that UI is setting to the same setting as default, just clear the exception.

c#9: I'm not clear on what additional utility is gained from being able to clear the exception back to default on Android as opposed to toggling it.

Clearing the exception when setting it to default seems weird because you could have the effect of toggling the exception, then having it disappear because you set it to the same as default and therefore it's gone. Am I missing something? :)

I guess one use case would be to get rid of some porn site in your exceptions list.

Just an FYI, in case it helps: the desktop UI in chrome://settings/content for setting Allow/Block for sites also includes an option to Remove the entry to clear it back to default.

c#11: in that situation, would the user be okay hitting clear and reset data if you wanted to get rid of it entirely rather than individually clearing the exceptions they've stored for it?

@13: probably yes

Hey! We are hoping to change the popup blocker to have an additional, stronger option (which BLOCK will use), with the existing default behavior moving to ASK.

If we implemented this, the default (ASK) and BLOCK will implement different behavior, so it would be nice to have a way to reset back to ASK without clearing all the site specific settings.

The worry here is that BLOCK will be too harsh for many sites (it blocks all new popups regardless of gesture), and we don't want users forced into ALLOWing all popups if they move from the default.

Re-org means that Android-specific work is moving off my plate.

Putting this on privacy team's radar (although technically already covered by Enamel*AndFriends* :) ).

estark@, should we find another owner inside enamel for this?

Not yet clear where this work is going to end up after reorg, but privacy team is a candidate IIUC (#19)

+engedy

Issue 917830 has been merged into this issue.