Open Bug 176773 Opened 22 years ago Updated 10 years ago

Consolidate various managers (cookies, pop-ups, images, passwords etc.)

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: jg307, Unassigned)

References

Details

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.
Summary: [RFE] Consolidate various managers (cookies, pop-ups, images, passwords etc.) → [RFE] Consolidate various managers (cookies, pop-ups, images, passwords etc.)
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.
Assignee: mpt → blaker
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → paw
Summary: [RFE] Consolidate various managers (cookies, pop-ups, images, passwords etc.) → Consolidate various managers (cookies, pop-ups, images, passwords etc.)
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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 
Blocks: 209454
*** 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.
Assignee: firefox → guifeatures
Product: Core → Mozilla Application Suite
*** Bug 284672 has been marked as a duplicate of this bug. ***
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: pawyskoczka → guifeatures
Component: XP Apps: GUI Features → UI Design
Resolved in Data Manager bug 569341?
You need to log in before you can comment on or make changes to this bug.