Once bug 270170 has landed, I'm looking at splitting the site management part of cookies from the view/management of cookies themselves and redesign the cookie pref screen along similar lines to the cookie prefs screen on firefox. At the moment the cookie prefs screen runs off the bottom of the preferences page and various options that probably be disabled at certain times are not.

"for the originating website only" and "based on privacy settings" will not both be able to be checked at the same time the logic will uncheck the opposite to the one being checked. Both can be unchecked though. "based on privacy settings" and "View Privacy Settings" will only be visible if P3P is installed. Everything apart from "Cookie Sites" and "Manage Stored Cookies" become disabled when "Allow websites to set Cookies" is unchecked.

could you attach a pic of the current cookie pref page for easier reference

What it looks like at the moment

hrm. a) the proposed stuff has more holes in it than the current design, but I'm not going to review at length here. Suffice to say: needs-work+ b) there's disabling issues, there's bugs on those, but seamonkey hacking is pretty far down my list. c) spilling by one line because one word wraps isn't much of a reason to rewrite the prefpanel. d) this doesn't look much like "sustained engineering path, stable UI/features" e) why are we bringing back "the blurb" at the top? We agreed last time around to kill it. If a user wants to know what it is, they'll click Help. d) probably concerns me most. The previous UI was pretty bad, so we cleaned it up, but redesigning again in another radical departure. I'll leave this open pending you convincing me that we need to rework this, again, for a "stable" project. If you convince me its worth it and appropriate, then we have some significant changes to make.

Just saw the screenshot of the new preference dialog, and I am not convinced. I find information harder to find, and also UI inconsistency. Why should the first line have the [cookie sites] button on the right of the text mentionning cookie sites, while the [privacy settings] button is not placed at the same line where "privacy settings" is referenced? One thing that I also found disturbing was the fake alignment below the "based on privacy settings" and "Cookie lifetime policy" lines. It looks like the sheft should be more shifted to render nicely. But that's perhaps because of the draft issue. Finally I liked the 3 blocks in the former UI. They structured my reading and helped me focus on less information on the UI. Now everything is in one block BTW why do you need it? The title of the page is Cookies and the block is cookies as well. Looks like lost space to me. One question: why one does open this dialog? I open it most of the time to manage my stored cookies. It may not be representative of the main usage, there are 2 distincts use of the cookies dialog. - set up the cookies preferences - manage the stored information (sites, cookies) Those who accept cookies probably almost never reopen it, isn't it?

(In reply to comment #1) > "for the originating website only" and "based on privacy settings" will not > both be able to be checked at the same time the logic will uncheck the opposite > to the one being checked. Both can be unchecked though. Don't Do That. Checkboxes aren't radiobuttons. I don't expect a checkbox to switch off another checkbox. (And why isn't this in the cookie component?)

screenshot of the Cookies pref. Monitor resolution 1280 x 1024, Win XP styles applied.

Monitor resolution is affecting the display of the pref panes in Win XP. If one is using Windows XP styles, the Manage Cookies button is not visible at all. I have to switch to Windows Classic mode to use this function. This bug is affecting several of the prefs panes' display, but it's a real pain for cookies, as this is the most common reason for going in to the prefs. I vote for providing splitting this pref and putting manage cookies on it's own pane.

The missing manager button would be a different bug. Not this one.

Not going to hold up SM 1.0a for this.

Ian, Are you still working on this ?

Yes, way down the list though.

As far as I am aware no longer an issue with pref panel size and data manager should cover the other side of this bug - WONTFIX