Previously as attributes browser/plugin data used to be editable which made it possible to add multiple URLs to allow and deny to the websites that needed it without the need to visit each URL one by one and accepting or denying them individually.
The point of custom plugin data is that we do not want a human to edit it. This is better handled by a dedicated UI element.
I accidentally hit deny instead of accept after ticking "remember decision" in the firefox plugin (I blame it on not enough coffee this morning). How is it intended that I would fix this then? Delete the plugin entry entirely and start over?
It is very easy to remove settings stored by a plugin. Just edit the entry that you are concerned with and:

I hope this is not considered to be the long term solution. The user then has to revisit all the sites besides the one they wished to remove in order to re-allow or re-deny them as needed. What if the entry is a single sign on that has many subdomains it works on, but others where it shouldn't be suggested? These must all be added back to the entry manually. Clearing the entire property is a frustrating solution in this case.
As stated above: "This is better handled by a dedicated UI element."
Well, until such a thing exists, can we make the properties directly editable then? Otherwise this is just a restrictive step back from the old method where the user could edit the data as needed.
@droidmonkey How can we correct / edit a domain whitelist via browser plugin if it is not possible in the main app ?
We are building that functionality right now, see #3444
I have same issue, very frustrating to start all over again when only one site (of many) in the allowed/denied list needs to be changed/removed. That new setting of #3444 does not solve this specific issue?
Also there is/was issue with ask dialog when multiple site are matched. You want to deny for one, and the other allow. But when remember decision for one, it also sets it for the other. Could not fix myself, because of no edit possibility.
As stated before, I see at least two missing functionalities in my use case :
Just had this issue, after 2.5.1 upgrade got asked for ~12 entres on a SSO page. Accidentally allowed them, now had to go through each entry and remove it.
Even if we allow this to be edited, we need a much better solution in light of #3779
Same issue here.
Not being able to edit (whatever the way is) is really annoying with SSO...
And the result of it and not being able to allow one entry and deny all the others is simply always having either the popup (and then clicking to fast on the bad button, some times with the remember option ticked) or dozens of proposed credentials in the username field. Both cases are really unpleasant.
Yeah I also now only had the choice to disable the stuff for all 12 credentials and go with auto-type.
Having a simple UI in the browser extension makes sense for most users. But it also makes sense to let a power user edit this data by hand. In many other programs the same could be achieved by the user editing a text file, but that's impossible with KDBX databases. Having the text field editable (even if it requires enabling some kind of advanced mode) seems like a practical and reasonable solution to a problem that quite a few people have.
Most helpful comment
I hope this is not considered to be the long term solution. The user then has to revisit all the sites besides the one they wished to remove in order to re-allow or re-deny them as needed. What if the entry is a single sign on that has many subdomains it works on, but others where it shouldn't be suggested? These must all be added back to the entry manually. Clearing the entire property is a frustrating solution in this case.