I would consider this a special case of  Issue 614618 .
But if there's a reasonable way to fix  Issue 614618  without fixing this, I don't mind keeping them separate. Do you see such a way?

Some context to #1: as far as I understand, the inability to override an inherited setting with Ask (except for Flash) is "working as intended" for our current permissions model. However, it would be nice if our model either naturally supported it, or were structured in such a way that you wouldn't "want" to do it this way.

But the UI is still doing something wrong in either case.

Ah, thanks for pointing that bug out. It happens to have has fixed itself, as we now scoped all permissions to origin by default :)

Re #4: Right - according to the model it is kind of expected, but the UI is currently wrong :)

I think disabling it in this case and making it clear how to undo the manual exception is the right way to go, but that will require design work and probable improvements in settings.

assigning to Raymes as general owner of permissions model

benwells: I think I agree with your suggestion in the original description in terms of simplicity. One problem is that currently per-origins settings actually have a higher precedence than broad exceptions. It would be a fairly significant breaking change to change that. We would need to determine how many users it would impact and whether the breakage would be worth it. 

One of the use cases we've seen is that some people want to be able to broadly block something (like Javascript on all https) but enable it on a case-by-case basis. Changing the way exceptions work would make this impossible to do.

Another approach to this would be to treat exceptions more like embargo. That is, they apply on top of defaults but are overridable by users for specific sites. This is basically the behavior today. The challenge then is how to do the UX. I think there could be some reasonable solutions there. Probably not as clean as what you're suggestion in #0 but still reasonable.

OK. Seems like we have a few options and can come up with something good, once we have the time to implement it...

 Issue 614618  has been merged into this issue.

We have a doc about this here: https://docs.google.com/document/d/1XxLt9tlNizWDMbO_gWegVnZs_kNM1anI1vR56fjRhf0/edit

Now we just have to find time to do the work :) 

*** UI Mass Triage***

Tested on latest Canary #72.0.3618.0 on Windows 10 and was able to reproduce the issue as the issue seems to be fixed. Hence, adding appropriate labels.

Thanks!