Closed Bug 7380 Opened 23 years ago Closed 9 years ago
Backend support for all page prefs on a URL by URL basis
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 ...
Summary: Support all prefs on a URL by URL basis. → [RFE] Support all prefs on a URL by URL basis
A small part of this -- the cookie part -- has already been implemented in 5.0.
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.
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.
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.
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.
Component: Pref UI → Preferences
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?
Move to "Future" milestone.
Target Milestone: M20 → Future
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → 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.
Assignee: vishy → mstoltz
[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.
Target Milestone: Future → ---
This could probably be accomplished using the PrefBranch interface, ccing bnesse.
Status: NEW → ASSIGNED
Mass adding mozilla0.9 keyword (mass changing milestone doesn't seem to work).
Setting milestone to Moz0.9.
Target Milestone: --- → mozilla0.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.
Target Milestone: mozilla0.9 → Future
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>.
Summary: [RFE] Backend support for all page prefs on a URL by URL basis → Backend support for all page prefs on a URL by URL basis
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.
Assignee: security-bugs → nobody
Status: ASSIGNED → NEW
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.
Priority: P3 → --
QA Contact: bugzilla → prefs
Target Milestone: Future → ---
Component: Preferences → Preferences: Backend
Product: SeaMonkey → Core
QA Contact: preferences → preferences-backend
As filed we aren't going to fix this. There is a separate system of per-domain permissions.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.