If you want this you'll need an extension. 1. the avg user will never use this 2. most pages will bring up the dialog, driving you nuts w/i an hour or so WONTFIX
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
yeah, it seams i made the wrong call I looked for duplicate bugs (plenty) and they very vague reopening
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Thank you, I appreciate it. Oh, and I am guessing that a gmail email address means that you are a volunteer, so thank you again.
First, the assertion that providing white/blacklisting for end users will have _any_ positive effect on security is placing far too much onus on the user. We should fix security holes, and make updating safe and easy, not leave it on people to inspect js code before enabling js for any particular site. This isn't something I want to try to address in the current cycle, but there's got to be a way of balancing finer-grained controls with something users can understand...
since the older bugs date from before the current UI (and are duped against a seamonkey bug) I'll set this one new status->New comp->Preferences os->All target->future
Status: UNCONFIRMED → NEW
Component: Security → Preferences
Ever confirmed: true
OS: Windows XP → All
Target Milestone: --- → Future
That's a completely invalid assumption. The reason we can selectively blacklist or whitelist sites for different content types is because mvl wrote a bridge between nsIContentPolicy and nsIPermissionManager, so anything the content policy interface could distinguish can now be manipulated by the permission manager. This is a backend feature with a lot of potential applications, not all of which are necessarily core UI features for Firefox. Just because we can utilize a backend feature from Gecko doesn't mean we will, or we should.
You need to log in before you can comment on or make changes to this bug.