We may also want to iterate on the language to convey how long the duration of the embargo will last.

dominickn: do you have time to look at this? Or should we find someone else? 

What is the benefit of having a separate menu item as compared to the explanatory "Automatically blocked" string?

The difference between "Automatically blocked" and "Always block on this site" in the menu is very subtle, and we would have a weird situation where embargoed items have 4 items in the drop down, but non-embargoed items only have 3. That doesn't seem very good to me either.

The idea would be to replace the "Default" item with the "Automatically blocked" item. This is conceptually what it maps to in the model.

The benefit is that it's more clear that it's in a temporarily blocked state. The user could then change it to always blocked if they want to. 

Replacing the default state like that would mean that the user then can't clear embargo from page info - they can only set it to Allow or Block. We'd be moving from having no ability to move from [Embargo] -> [Always Block] to having no ability to move from [Embargo] -> [Ask, wipe embargo].

Also, I'm not sure that the inability to change from a temporarily blocked to an always blocked state in page info warrants this being a P1.

> Replacing the default state like that would mean that the user then can't clear embargo from page info 

That's a good point. To be honest I don't think many people would want to change it from Embargo->Always block anyway. Maybe we would just want to change the language from "Always block" to "Temporarily block" or something...

I'll make it P2 for now.

I think we should od the change suggested. It feels weird as it is because the three states of the underlying model don't match the three states in the drop down.

Re #6 - what's wrong with the user not being able to clear embargo? Put another way, why would a user want to clear embargo but not go to the allow or block state? If someone wants to allow or block permanently they can do that by setting to allow or block.

c#8: We have explicitly told developers in the chromestatus entry and on several bugs that they can use page info to reset embargo while testing (https://www.chromestatus.com/feature/6443143280984064). This would need to be revised to "clear your browsing data", which is less accessible and surgical than page info.

I'd ideally like to have all permutations (embargo -> block, embargo -> allow, embargo -> reset) available in page info, but that's not possible with only three menu item states. So if we have to pick two, it's not really clear to me why having the ability to move from a temporary to a permanent block state is more desirable than having the ability to reset embargo by moving back to Ask.

Put another way - if the permission state is "Automatically blocked", how often would a user open page info and want to make it "Always block"? Like I mentioned before, I think the distinction between the two is very subtle, and telling an "Automatically blocked" state and a "Always block" state in the drop down apart would be difficult.

Maybe that means we need to block any improvements on a better way for developers to clear this state. Long term though I think we should make a change. Embargo as it is now, to me, obfuscates the underlying model. We should aim to have the UI more clearly map to the underlying model.

We should, in the long term, prioritize users over developers.

To me this isn't about having the most useful actions available, although it is important we don't remove any important actions. To me it is about having the options in the drop down map to the three states that sites can be in: default, allowed and blocked.

Strawman:

Replace the "Automatically blocked" string with a link to "Reset temporary block". Change the embargo state in the menu to be "Temporarily Blocked" (replacing Default).

In the underlying model, embargo is a variant on the default, that's true. My key concern though is that functionally, it's a Block, and introducing a non-Block state that says Block is potentially confusing. In this strawman, we would have "Temporarily blocked" versus "Always block for this page" in the menu drop down, which is less confusing that having "Automatically blocked" and "Always block for this page". I'm still not a huge fan of this though since there are two "block" like states in the drop down (and now the way to reset back to an Ask state is outside the drop down, which is inconsistent).

I view embargo in the same vein as policy or extensions, which are external factors that control content settings. Embargo is overridable, unlike the other two, but ideally we would use consistent UI across all of these since they sort of work in the same way. Using the "Controlled by X" / "Automatically blocked" string that we currently have feels like the most consistent way of communicating that there is an external factor that has modified the state.

In current state it _is_ possible to go [Embargo] -> [Always Block]. You do that by selecting "Always block on this site" (i.e. by manually selecting already selected item).

Also clarification for [Embargo] -> [Ask, wipe embargo]: it's worth pointing out that the counter of dismissals is never cleared. The domain that went to Embargo state once, will go to embargo at every prompt dismissal. Neither selecting "Ask" manually nor clearing site data clears that.

As for lack of possibility to go [Embargo] -> [Ask]: this would be somewhat consistent with Android Chrome, where IIRC it's also not possible to go back to Ask after selecting either Block or Allow. On the other hand, some users may want that if they want to give the page the permission, but only sometimes (but Embargo likely brakes the experience for them anyway).

I think Embargo should be represented by another entry in the dropdown, named "Block temporarily" or "Block for X days" (with dynamic X).
I'd say that from user perspective this is a 4th state, not exactly equal to any other. Embargo state is _automatic_, but I'm not convinced we should consider it to be _default_. The page was in default, and then user action happened, that changed the state. So I'd rather think of it as "Block for X days, and then go back to default".

I'd keep current "Automatically blocked" annotation. It indicates that the change happened that wasn't requested by the user.

> Also clarification for [Embargo] -> [Ask, wipe embargo]: it's worth pointing out that the counter of dismissals is never cleared. The domain that went to Embargo state once, will go to embargo at every prompt dismissal. Neither selecting "Ask" manually nor clearing site data clears that.

Clarification: clearing site data resets the counter to 0. Selecting Ask manually does not clear the counter.

To me, introducing a 4th state is even more confusing than relabelling the "Default/Ask" state. Like I said previously, from the user's perspective, embargo is Block. Permission requests are blocked in this state. The temporary nature of the block feels more like a "state modifier" than a distinct state in and upon itself.

Another argument against having a 4th state is that users probably shouldn't be able to put a permission back under embargo if they explicitly move out of that state. But then we have a situation where the drop down originally has 4 options (embargoed), then suddenly it has 3 (change to non-embargo, and the embargo state disappears).

I agree that having 4 states is probably confusing for users. I actually think even 3 states is too much cognitive load, but that's probably a discussion for another time :) 

Having a "Reset temporary block" would be good for developers, but not sure it would be the best for users. I wonder how hard it would be to add a single "Reset embargo" button in devtools. Alternatively I wonder if a command line flag would do for now as a stop-gap solution? dominickn@ wdyt?

There's a "clear storage" section in devtools where this might fit naturally?

Deleted: Screenshot from 2017-07-12 11:52:30.png 50.9 KB

	Screenshot from 2017-07-12 11:52:30.png 50.9 KB View Download

I'd prefer a devtools based option over a command line flag (strictly speaking, you could pass a disable-features flag already if you really wanted to). Devtools should be where developer-oriented things go in the long run.

Evidence suggests that this isn't P2. Is there any plan to do more work here?

This is a nice to have but there's probably no plan to invest in it more at this stage.

Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!