I think that, with the addition of the pop-up manager, the tools menu has become unwieldy: the similarity of the various items (each ends 'manager') makes finding the required option slower than is necessary. In addition, many of these dialogs provide similar functionality but acting on different objects from a particular site. I propose that it would be beneficial to reorganise the front end for these options. There are a number of ways this could be done, I have one suggestion, which I will outline below. Start by creating a new dialog with a title such as 'Page Permissions'. This would then contain the options relevant to the domain (or page) being viewed specifically with options like: Allow cookies from this server Allow page to set cookies from other domains Allow pop ups from this server Allow images from this server Store passwords for this page (Something similar for forms) This clearly has the flexibility to cope with future functionality e.g. allow this domain to excecute scripts. Some of the preferences options could also be moved into this interface, as long as they could be set on a page by page basis (this would require some backend changes). The preferences interface could then be rationalisesed, so rather than having seperate pages for pop-ups, cookies, etc. they could be grouped under 'Default permissions' - and they would have exactly that functionality - to set the deafult. (although this would not be required). The page permissions page could then be linked from the view menu and maybe also the page info dialog box. On the tools menu, would be options like: Block cookies from this site Block images from this site Block popups from this site Save form info These would be at the top level and so easier to find and use. Clearly there would be a need to see the information stored by a particular page e.g. passwords, form values and cookies. This could be simply implemented as tabs in the page permissions dialog, or could be a seperate dialog (again under the view menu). This, again could be linked from the page info dialog. As a final stage the overall listing of all sites for which anything is stored (cookies, passwords, form) should be consolidated into a single dialog with a name such as 'Manage stored information' (or maybe something shorter). This could be on the tools menu. In fact, I am sure that there is an even simpler way to implement this, but I'm not sure what that is. I do think that the current plauge of managers and related preferences is difficult to use and doesn't give the impression it has been coherently designed, more slung together as each new feature was implemented (which AFAIK is what actually happened). Finally: if it is required I am prepared to learn XUL to try and implement some part of this or a better suggestion (i.e. the front end) myself, should there be any interest but no avaliable mozilla / netsacpe / other regular contributers. This would of course be to the detriment of the speed and quality of implementation.

James, XUL allows you to create such a manager on your own, and test it on your own computer. Then, you can distribute the result as an add-on, or submit it to Mozilla developers for possible inclusion into Mozilla package. That would help everybody; that's what Open Source is about.

Yes, I realise that. However before I started on such a project, it would be nice to have some external input on what would be good / bad, hence the bug report / RFE. Also, I might have missed a bug somewhere, so someone else might be working on something similar. And, if the bug is wontfixed for some reason, there would be little point in doing this - I don't use these options very much but it vaugely annoys me every time I open the tools menu, and I think it would be good to improve before 2.0. As a reorganisation of the menu structure, I don't really think of it as extension - although that's clearly not a technical distinction. If someone familiar with moz were prepared to take this, it would certianly be be implemented faster than I could manage. However since this is open source and it is an enhancement request and I ought to be able to do it, I am prepared to try and 'fix' this as you describe. It would just take a while, that's all.

To my best knowledge, we don't have such a bug yet, because we didn't have so many different managers until recently. So go ahead and work on it; even if you won't come up with something worthy, you will still receive a valuable expierence.

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

From the dup: bz thinks this is a dup of an even earlier bug.

uid is being phased out.

I think this is a good idea. It should be very easy to get to the manager screen for a particular site. In fact I don't think it should be on the page info screen; it should be directly in the right-click menu ("site permissions"); or else, the site manager stuff could go directly into the page info screen, rather than being linked to a separate screen. Paul Rubin <http://phr.cx>

I'd like to suggest going even further than consolidating these "managers" which are simply UI hooks to preferences controls deep inside the browser. There should instead be a way to call user-supplied javascript on EVERY browser navigation and allow the javascript to modify the outgoing http stream (at least the headers). That would let it filter out or rewrite cookies, user-agent headers, referer headers, etc. Even bugs like bug #78104 could be handled this way. A reasonable model to use is MSIE's Browser Helper Objects which are COM objects that get called on certain browser events like navigation. I've made a this suggestion in a few related bugs and should probably open a new RFE for it, but am not familiar enough with Mozilla internals to make more precise suggestions.

I would suggest to confirm this bug - the current UI is very user unfriendly and clearly reflects the software architecture instead of the user's interests. Changing the UI to an architecture that is based primarily on hosts and groups of hosts, where all the permissions are kept together is something that would make these feature much more usable. I think doing this as an extension first would it make *much* easier for many users to test it, give you feedback, and spark discussion - outside of bugzilla. This bug could in the meantime remain open, indicating to all what is underway, giving the apropriate pointers and waiting for a polished addon to get included in the trunk.

Marking NEW. There's lots of bugs that are similar to this but no-one's yet come up with an exact duplicate and I couldn't find one. This bug is relatively restricted compared to others, involving only front-end changes for the existing site-by-site prefs UI, though it could come in handy if bugs like bug 7380 are fixed in the future. In addition, the reporter has indicated a willingness to try and fix this himself, which puts it ahead of most RFEs.

Pardon me, blaker. But this will only affect the FE? Because if it affects the BE, we have some near dependencies to mark: http://bugzilla.mozilla.org/show_bug.cgi?id=189149

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

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

Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). If you want this fixed for Firefox, change the Product and Component accordingly and reassign back to me.

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

Filter "spam" on "guifeatures-nobody-20080610".

Resolved in Data Manager bug 569341?