There is a growing call for users to be able to choose preferences that differ on a URL by URL basis. Examples of this from a quick search are Javascript on/off on a domain by domain basis (bug #858), the n.p.m.wishlist threads "Images OFF for specific web sites?" (which has some useful commentary), "enhancement propositions" (which contains a proposal for selective cookie acceptance), "download filters" (which contains a proposal for different download directories), "site-specific java toggle and global (or sound toggle" (javascript again), and the n.p.m.ui thread "Disable Javascript from specific domains." (you guessed it). So you could see that, even in my quick search of newsgroups, there is quite a demand for this sort of functionality. Turning off Javascript is popular but it shouldn't be the entire scope of this enhancement. The following is a list I've compiled from my head and the NC4.6 prefs dialog: Security: JavaScript, Java, Cookie Acceptance, Chrome Replacement. Display: User Style Sheet, Colours, Fonts, AutoLoad Images Other: Preferred Language, FTP Password Passing, How Often Compared To Network Note that if you did this with proxies it would provide a more general solution to "no proxy for:" Obviously this would have a significant effect on Prefs, but also probably in places like Netlib and Layout. Handling the problem for all URLs, yet allowing regexps allows domain/file extension matching. A media type might also parameterise a set of prefs, although this is not possible for all of them. The major issue then is how to handle this in Preferences. The aim would certainly be to not make it harder for users who don't use it. So how? (a) Simply enhance all relevant widgets to allow a hierachy of patterns and pref values (where the root node means "Default" and the most specific node is used). If you wanted to go this route you might allow specifications of a list of "patterns", to allow a pattern to be centrally changed. (b) Split off these preferences from the others, with a different section, and provide one hierachy of pattern vs. all pattern-by-pattern pref values. You would use stuff like tri-checkboxes to inherit the parent nodes values, and could override some of them. This might be simpler than (a) since many prefs might have the same pattern hierachy. (c) (b) is a bit constraining, since it is a single-inheritance hierachy, and all prefs must follow a specific hierachy. Instead you might compromise, and allow hierachys for multiple prefs. Hierachies for one pref would be (a) and for all would be (b), but you could choose anywhere in between. You would start at the root node, see if any other patterns match below it, and if so, go down into that subtree, and so on until you can't match any children or have reached a leaf. Preventing multiple patterns matching at the same level is an issue to consider.

As an addendum, I'm not in the slightest expecting this to be implemented for the initial Moz or NS5, but it's a sort of heads up that you can point people to who make this request, and allowing thinking about this sort of issue before it gets implemented in an ad hoc fashion. Perhaps it could be assigned to noone if Bugzilla allows it, as I think most rfes not taken up by the module owner should be. If this is not possible I might put in an RFE to Bugzilla to allow it. I would think this would be a better solution than marking the rfes "later" or "resolved" or "will not be fixed" or whatever.

Move this out to M14 for now until I can slap some marketing people around ...

A small part of this -- the cookie part -- has already been implemented in 5.0.

Which is very cool (this is the most important imho). When I've looked at the Pref UI recently it looked very much like the 4.5 settings, so if it's there I've missed it. How will the UI for this work in 5? I presume it will work using scheme a, since the others are only really necessary where you have multiple prefs on a URL basis. It's probably fairly sensible to ensure that cookie acceptance is based on the site rather than the URL, but I worry a bit that from a reusability point of view this might be suboptimal. One intention of this bug is to highlight the fact that these are all really the same thing and should be implemented as uniformly as possible. Hence it would be better to try and design as much reusable framework as possible. This includes the prefs widgets, the back-end prefs stuff and algorithms for determining the value. So for example, prefs would have a call: CookieAcceptance( "http://www.mozilla.org/status/" ) that would return the relevant value in {Yes, OriginatingServerOnly, On} and so on. Then there would be another call JavaScriptOn( "http://www.mozilla.org/status" ) that would use the same searching algorithms (explained briefly in the original report), just for a different preference. Or maybe it would be one procedure and take a parameter as to which preference it concerned. If this is not possible, feel free to tell my why and I'll proceed to go away. =) Anyway, I doubt this is happening at the moment, and while it may be able to be changed later, with all the talk of XPCOM scriptability and JS in XUL files, I'm a bit worried that it might become impossible later. Also, I should add "background sound on/off" onto the list of these prefs.

Here's a look at the preferences and how I feel they differ. JavaScript - URL-By-URL Java - URL-By-URL Cookies - Site-By-Site Chrome Replacement - URL-By-URL Style Sheet - URL-By-URL Colours - URL-By-URL \_ (Covered by style sheets?) Fonts - URL-By-URL / Auto-Load Images - URL-By-URL ( + Media Type?) Preferred Language - URL-By-URL FTP Password - Site-By-Site How Often Compared To Network - URL-By-URL + Media Type Background-Sound - URL-By-URL (+ Media Type?) Download Directory - URL-By-URL + Media Type There's a little bit of differentiation. This could well mean there could be multiple or one parameterised prefs panel(s), however I still think the pref lookup interface should be uniform, especially since this allows changing it later. The call should probably include media type too, something like: ComplexPref( PrefDownloadDir, "ftp://foo.bar.com/stuff.tar.gz", "application-xcompressed" )

Bug# 858 discusses the JavaScript capability issue specifically.

Yeah, I mentioned it in my original report. =) Marked a depends relationship of this bug on 858 since it looks like 858 won't be closed as a duplicate of this (I guess since 858 might be implemented in v5) whereas this almost certainly won't.

Whether to activate automatic form filling is another option here.

As might be bug #8648, what to do when a redirected/not found site is found.

And bug #15145 on preventing image (GIF, MNG) animations.

Bug #15148 discusses affecting these options through the UI while browsing.

How about a menu (called security or options or something) whith the following structure. Cookies > Menu A JavaScript > Menu A Images > Menu A Menu A (cookies example) > Disable/Enable (inteligent) Cookies > Never use cookies on these sites > Menu B > Always allow cookies on these sites > Menu B Having never and always up is needed, so people can switch in and out of cookie accept mode, yet still have access to these lists. Menu B > Add current site > Edit sites > ----- > www.microsoft.com > www.msn.com > www.dodgy-cookies.com Edit sites would bring up an edit>bookmarks style box. You could also have a 'zones' option, much like IE's run using the same sort of idea. You would define a zone with a name and checkboxes for javascript, cookies etc Is this practicle?

What you describe is already implemented for cookies I believe. See Edit/Display Cookies, the "Website Setup" tab. This bug is about a general architecture for all these sorts of things but also (a) allowing it to work down to the URL level and take media type into account, and (b) to allow you to specify a tree, eg x is allowed, but not x/y, except x/y/z which is allowed.

Another option is whether to cache, bug #11644, which would be interested in both URL and media type.

*** Bug 14823 has been marked as a duplicate of this bug. ***

From 7380: === It would be awsome to have a simple regular expression blocklist to block banners and the like. It might even be useful as a net nanny. This would solve alot of trouble coused by using the proxy variant. It could visually work in some diffrent ways: 1. Show the object but do not load it until clicked on (like the do not autoload images). 2. Do not load or show the object at all. These would preferably be a selectable otion per regexp. Maby a deny - allow sheme whoud be useful in some situations. /Dr === That is basically the same idea as this, with the pref in question being "download images" and the URI being the image's (rather than the site's).

When I said "from 7380" I actually meant "from bug 14823". This _is_ 7380...

Turning off auto-load images for this would be a way to prevent loading. Of course, you might want to remove the content entirely, ie no alt text, which would be different.

Yet another option would be to block by the text content of an page to expand the net nanny ability. Also an option for frames autoloding might be of interest. And an option for redirects and meta http-equiv refreshes.

I think it would be difficult to visualize a tree. I would recomend a first match list instead: Deny/Allow/Click Type Regexp Media type ---------- ---- ---------- ---------- Allow Java http://java.com/.* .* Deny Java .* .* Allow Auto-load .*advanced.* .* Click Auto-load .*adv.*.gif .* Deny Cookies .* Deny Content .*porno.* .* ...Um, you get the picture. Not perfect but...

Hi, This is a very useful feature, but to stop it from becoming a geek-only thing, it should be: a. very easy to reach. b. have a lot of defaults. How about this: 1. User is browsing www.tunz-o-images.com, and doesn't want to load them. 2. User clicks Edit, and below "Prefs" he sees "Customize this site". 3. He gets an incredibly banal wizard, where he can choose from a few options: -- Don't load images for this site. -- Don't open popup windows from this site. -- Place files downloaded from this site into [browse] -- Ask for a password before showing this site: [editbox] -- Customise... 4. Customise should give a crippled pref window. There's not much to cripple, though. For example, where my dad works, he has to access some sites from one http proxy, and some others from another one (some wierd MedLine license) As to viewing the list of "site rules" or whatever - a bookmark-like window would be just the thing. There should be a 2 phase setup here - at first just a text saying what was changed ("Disable Java. Don't load images."), then a "Change..." button giving you the crippled pref window.

I would suggest that the matching not be by lists of sites or urls or regexps, but that it be implemented by a javascript call. Surely, the default javascript should do something simple like keep a list of sites or urls, but I think it'd be neat for knowledgeable users to be able to get in there and hack. ("The emacs nature is good.") I conclude this from my experimentation with this kind of thing.. I (ab)use the proxy autoconfig capability of communicator to block out banner ads, and awhile ago I wrote an implementation of javascript cookie filters (an early predecessor of the fancy cookie support that's in Mozilla now.) Now admittedly my scripts are basically matching against lists of regexps, but it's nice to know that I have a turing-complete language available. (My js mail+news filters really do have fancy logic.) See the proxy autoconfig docs at http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html .

I'm not sure filtering Nanny capability should be here. Firstly, you might want to lock off these preferences separate from the rest of the others. Secondly, blocking a page tends to make the other prefs irrelevant, and so they are not orthogonal. Thirdly, this could work on page content, whereas all the others don't. It could work similarly but I don't think there's benefit in allowing it in the same tree. You could use a match list instead of a tree, the functionality is the same. The tree is basically meant to make it easier to visualise, for experts at least. You could use the tree as a match list by checking things in order at the same level. The tree basically aims to make this easier: a & c -> a & b -> a -> becomes: a -> b -> c -> Re: usability. Ideally it should be fairly simple in the simple case. This has to be worked out. I might try to hammer out a spec shortly. Re: javascript. I always intended on allowing boolean expressions, like with the current filtering, but if this is done it should be complementary. I do not wish to learn Javascript to do this, as with most users (and I'm a programmer).

Re: Javascript. No java please, but implement it in a loadable module so the ubergeeks can do whatever they want. I'm really concerned about speed here, since this function would be called for every access and it might test alot of things. So the default a c-module, with the ability exchange that module with your favorite Java/Pyton/Whatever module. Re: Nanny split off. Hmm, good point, maby it could be several lists: Create list 1, Nanny, set password. Create list 2, Bannerstopper Create list 3, Misc. Still, first item match in listorder. Otherwise you would be able to allow a thing previosly denyed by the nanny. An ability to shuffle the list around would be nice, but the password protected stay put (unless password given). One problem: An allow in the nanny might contain things you want to deny in the bannerstopper. So a new actiontype: "Next" to make it to go to the next list in order (actiontypes = Allow, Deny, Click and now Next)

Bug #1582, whether to send the HTTP referring page, is another, although this one could be parameterised on previous or current page.

Bug #1785 is another bug that this subsumes. It is about Java, and illustrates the value of having a "prompt" setting for certain sites, along with a "remember this decision" facility. Cookies already have this facility, BTW.

In http://www.deja.com/getdoc.xp?AN=538355205&fmt=text I propose a GUI for this feature -- an extension of the prefs dialog to include what I called `browser zones', to specify different prefs for different sites/URIs. The UI deals with preferences for different mail accounts and news servers in a similar way, for consistency. It only makes sense to change *some* prefs on a URI-by-URI basis -- basically ones related to display of content (images, fonts, cookies, JavaScript, etc). These I arrange into a new prefs category -- subcategories can be adjusted for each zone, or left as the default. A given URI could belong to more than one zone at once, from matching more than one set of rules; if the zones' preferences conflicted, the last one would override earlier ones. So order of zones would be important. Considering the similarity between mail accounts, news servers, and browser zones may be of help when designing the underlying prefs architecture for this feature, too. Sticky points with the design: * If I choose to have a dialog asking me what sort of cookie permissions I want to give to a site (for example), I'm probably going to have to have a set of default zones for those sites to be plonked into. * I haven't considered the problem of changing prefs for messages on a message- header-by-message-header basis. We're almost getting into the area of mail filters here. Hope this helps ...

Move to M20.

spam: in my testing realm, so reassigning qa contact to me, en masse.

*** Bug 26272 has been marked as a duplicate of this bug. ***

Bulk move of all Pref UI component bugs to new Preferences component. Pref UI component will be deleted.

Gee, why not remove the bug entierly and admit it's never going to be done. First you move it to M20, then you remove the votes by changeing the voting rules to one vote per login, but only for this particular bug, not the others. This sucks!

Please don't jump to conclusions. M20 is not very far away, about 4 or 5 months. I would be suprised to see it begun to be implemented before that time, since it is significant work and I expect Mozilla to stabilise around then. This is an enhancement request, and it doesn't have to be fixed immediately. There are things I would much rather have first like a rock-solid Mozilla release. This will occur in time as it becomes a higher priority. The voting system for all Browser and MailNews has been changed bugs by whoever is in charge of it. Webtools still has the old system. Maybe this is the only bug you had multiple votes for, so therefore the only one you received a notification for? Venting your frustration does nothing to implement this feature. Maybe write it yourself, or find someone else willing to?

I think this is probably the place for my comments. I was reluctant to open a new bug. Basically, the idea I had was to have procmail-like filtering and mangling features on cookies. Basically, procmail lets you match incoming e-mail based on headers and content and take specified actions, which can be pretty much anything... one of the most useful being mangling the message. For example, if I get a cookie that expires in 2048, I'd like to squash that to three months from today. Or squash it to being a session cookie, or any number of actions... perhaps throwing up a custom dialog letting me know so I can e-mail the admin. Flexability is the key. (That said, it doesn't have to look like the procmailrc format, it's just the example I used...) I put it here because I think it could be easilly extended beyond just cookies... procmail-like filters on HTTP headers (and by definition, the set- cookie header (*)) might do the trick. (*) that might cause problems with javascript's setCookie method, but this is just a brainstorming comment. I'm curious to see if anyone else thinks this is a viable idea. (May want to move this to the newsgroups, as well... Hm.)

Move to "Future" milestone.

don, you futured this, should it be nobody'd? Deny/Allow/Prompt/Click. As previously stated there are two pieces to this, FE and BE. I suggest that this bug focus on backend support. There are a few other bugs that would handle the front end including: bug 42663 Preferences are inaccessible and app global [there's a huge debate about modality of prefs] of you put this in a sidebar it's easy to access and makes a bit more sense. wrt locking, I think each change you make would be live so having the sidebar open multiple times would cause it to refresh whenever a change is made [oh well, alternatives would be worse]. This really isn't a normal preference candidate because by its very nature it is not app global. IE's zone dialog is rather unmanageable. One important question: How should this persist? Since we're favoring regular expression based settings I don't think we can stick this into the history stuff. One other useful feature would be the ability to define a condition and apply multiple things to it. eg .*xxx.* : No Referer, No Java, No JavaScript, No Cookies I think this stuff is a good candidate for a database. For the expression to be able to affect multiple things, we could use the mailnews To: editfields which have completion (in drop down form). All current rules would be in the list of completions (making it relatively easy to reuse a form).

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

I'll take this, since I'm interested in re-implementing site JS prefs (was bug 858) using a common per-site prefs mechanism, as well as P3P (bug 62399) and possibly other features as well.

[from bug 60323: chatted with mstoltz and found that the frontend was covered by bug 38966. it's currently closed, but i might reopen it as an enhancement.]

[x] Accept cookie and destroy it immediately. Some sites insist on cookie (hotmail), some use for tracking. This wouls satisfy both sides.

I do not think that "Accept cookie and destroy it immediately" could work. The server (e.g. hotmail) sends a cookie to the browser and does not know that it has been set until the next request from the browser contains that cookie. So destroying the cookie "immediately" (before the next request) would be the same as not accepting it at all. Destroying it after one request (to the same domain) may not work either, because the sites relying on a complex login process involving several scripts and redirections will only check the value of the cookie after 4 or 5 requests. A better option could be to delete the cookie after a specified amount of time or "as soon as you leave the site", which is in itself hard to define. By the way, this suggestion for cookies should probably go to a another bug, because it is not directly related to this one, which focuses on the "prefs by URL" backend and not specifically on cookies.

clearing milestone to nominate for moz0.9.

This could probably be accomplished using the PrefBranch interface, ccing bnesse.

Mass adding mozilla0.9 keyword (mass changing milestone doesn't seem to work).

Setting milestone to Moz0.9.

Here's the interface I had in mind: nsISitePref::GetCharPref(in url, in prefName, out prefValue); which would return the value specific to "url" if there is one, or "default" otherwise.

You might want to also have a media type parameter for some prefs.

Matty, right, Mitch is aware of this. You found the bug for the backend support I was talking to you about in bug 24418. I don't believe we need special support for media type here - as long as we have a pref that supports that somewhere else, we can use it with this new interface.

Found it? I filed it!

This proved more difficult than I thought, so I'm putting it off. Future.

Can we at least get this in for javascript and java? IE has something like it for scripting, at least, and it would REALLY help me. As far as UI goes, I like the way we do it for cookies...

Who is 'we?' This bug is about the backend, and a backend already exists for Javascript, and for Java though they use separate mechanisms.

Here's an idea for consideration, please think this through and consider the various factors for perf, bloat, convenience, security, usability, and end user satisfaction etc. Perf hits can be minimised from regex impact by a few methods such as checking to see if it is a regex before applying the rule to the content. code bloat is a consideration but offset by combining the existing fragments of content control into a single group of functions. (Content Control is a nice 'section' to use for doron's new popup control UI see bug #75371) If the UI is well designed, the convenience for the user is noticable and appreciated, ties together with usability. If I had this feature, I'd be able to block all images if mail content has "click here" in it, and block a URI of http://host.com/cgi-bin/redir.cgi?ad.doubleclick.com without blocking host.com a) rule capability that applies to content acceptance and to rendering. (intentionally split) b) each rule can have component object such as: 1) mail | news | navigator c) each rule is based on selectors which may include but are not limited to nor required to have (regex selectors possible): 1) URI | mail header or body | media type | image size d) and are focused on media objects of: 1) images | cookies e) each rule's actions can be: 1) allow all | download but don't render | accept and bitbucket (cookies) | don't accept f) and can have a lifespan of: 1) forever | N days | session Some of these things are complex, they could be en/disabled w/ an [advanced] button. Comments?

*** Bug 160741 has been marked as a duplicate of this bug. ***

What about user agent customization per bookmark/site? For instance, some internet banks in Sweden have hardcoded checks on the user agent of the browser and won't let Mozilla show any pages, even if it is able to show the pages just fine if you change the user agent string that Mozilla presents itself as. Unfortunatly you have to do this by editing prefs.js by hand and you have to restart Mozilla between changes.

Can I add a request for per-site flash blocking. At the moment, all flash seems to be displayed if you have the plugin installed. I usually install the plugin when I visit a flash-only site and uninstall it immediately afterwards just to stop ads. Actually, a more generic "block XYZ plugin" per-site option might be better. Plus an "allow from originating site only" option similar to current cookie/image handling.

Would this enh. permit configuring a specific proxy to use for HTML email (either by selection of proxyMethod=DIRECT, or setting no-proxy-for to *)? The URL of the (parent/originating) HTML would be mailbox:*, while the URL of the objects it references (that need to respect the mail-specific proxy) are *:*. (everything). If I'm behind a firewall in a corporate intranet, I wish to configure one proxy for browsing the public internet. But when reading HTML email, I only want local (intranet, or same message attachments) references to resolve (in their many forms: CSS, images, plugins, src-ed JS...). Say you don't if it's spam or not and view a message anyway. Viewing of such an HTML email, especially accidently, should pose no possibility of generating hits of any type to an external web site (zero feedback). If I click on a link/href within of course, this visits that URL in a browser window using the ordinary browser proxy, not the mail-specific proxy.

How about allowing to block content according to html-element and its attributes? You could choose script, object, table with class-attribute with value "navbar" etc. Sometimes this would help to remove completely unnecessary white space which remains after blocking images with normal methods.

Re last 2 comments: Both suggestions exceed the scope of this bug (the latter is not even related). Please see <http://www.mozilla.org/feedback.html>.

I use a filter from PC magazine called Cookie Cop 2.0 and it has an option to make cookies from non-approved sites into session cookies. This works well for me as all the sites work since they don't know the cookie has been modified and I don't have to do any manual cleanup, just close and reopen IE.

Reporter, do you still see this in newer builds. Everyone, is this bug still ongoing in development? -R

> Reporter, do you still see this in newer builds. huh? This is an enhancement request*, not a bug you can "see". *and an important one IMHO Reassigning from mstoltz to nobody.

Please consider features presented by these .XPI files, maybe their coders would give over to this project as they fit some of the features being looked at. No Squint, NoScript, ABP.

As filed we aren't going to fix this. There is a separate system of per-domain permissions.