(In reply to bug 236980 command #c2) > HJ: this isn't the right bug for these comments, this is Firefox, not > Seamonkey. If you want to complain about the UI in Seamonkey, file a seamonkey > bug against me. I have a few problems with the modified cookies pre panel, here they are: Why doesn't the 'Block cookies' radio disable the 'Cookie Lifetime Policy' settings? We can now setup: 'Block cookies' and 'Accept cookies normally' and that can't be right! Can you please replace 'Accept cookies normally' with something like 'Use expiration set by cookies' or 'Use expiration specified by cookies'. There's nothing 'abnormal' about changing the lifetime of cookies. Can you change: (.) Allow cookies based on your Privacy Settings [_V_iew] into: (.) Allow cookies based on your [_P_rivacy Settings] Using 'View' for the button is not right, because you can also modify your settings. What is the purpose of: network.cookie.alwaysAcceptSessionCookies and pref.advanced.cookies.disable_button.more_info ? Can you change for="lifetimeDays" into control="lifetimeDays", because clicking on 'days' now won't select the 3th radio, as it should. Why did you remove 'Ask for each cookie' from 'Cookie Acceptance Policy'? What exactly is 'Ask for each cookie' now?

> Why doesn't the 'Block cookies' radio disable the 'Cookie Lifetime Policy' > settings? We can now setup: 'Block cookies' and 'Accept cookies normally' and > that can't be right! Oversight on my part, I don't remember why this wasn't done, but logically it should be > Can you please replace 'Accept cookies normally' with something like 'Use > expiration set by cookies' or 'Use expiration specified by cookies'. There's > nothing 'abnormal' about changing the lifetime of cookies. Accepting as sent is "normal" behaviour for UAs. Lifetime limiting is a Mozilla feature that IE/Opera don't appear to do (Opera does do clear on exit). Your text is wordier and less likely to make sense to users. > Can you change: > (.) Allow cookies based on your Privacy Settings [_V_iew] > into: > (.) Allow cookies based on your [_P_rivacy Settings] > > Using 'View' for the button is not right, because you can also modify your settings. This isn't a change I made, its been like that since p3p was implemented, and using button text in a sentence is terrible UI, IMO. Maybe change View, but what's the benefit to changing a button description that's existed for at least three milestones? > What is the purpose of: network.cookie.alwaysAcceptSessionCookies Automatically accept session cookies when prompting is enabled. (common RFE/IE parity) > pref.advanced.cookies.disable_button.more_info ? It disables the Cookie Manager button. (legacy of Netscape) > Can you change for="lifetimeDays" into control="lifetimeDays", because clicking > on 'days' now won't select the 3th radio, as it should. sure, trivial, 1.8a > Why did you remove 'Ask for each cookie' from 'Cookie Acceptance Policy'? > What exactly is 'Ask for each cookie' now? removed from what? That sentence doesn't parse. Cookie prompts now allow the choice of whether to accept as sent or limit to session, along with rejecting outright. I agree that its not the best option, but of the different options that were discussed, it was the best solution. the disabling and the controls= bits make sense, the rest is just opinion, and given that I worked this out with the module peers/owner and the primary seamonkey UI owner, I think there's consensus that the rest is what we're going with.

(In reply to comment #1) > Accepting as sent is "normal" behaviour for UAs. Lifetime limiting is a Mozilla > feature that IE/Opera don't appear to do (Opera does do clear on exit). Your > text is wordier and less likely to make sense to users. But we're not talking about IE/Opera here. I know what they do. > > Can you change: > This isn't a change I made, its been like that since p3p was implemented, and > using button text in a sentence is terrible UI, IMO. Maybe change View, but > what's the benefit to changing a button description that's existed for at least > three milestones? Well, using 'View' is simple wrong and not logical. You have to click on that button to find out that you can adjust your P3P settings in that window. Any button in mozilla should inform the user about what it does, or at least give a good hint. So View is wrong. > > What is the purpose of: network.cookie.alwaysAcceptSessionCookies > Automatically accept session cookies when prompting is enabled. (common RFE/IE > parity) Do we really need it? Where is that RFE? What is the bug number of it, I can't find it (: > > pref.advanced.cookies.disable_button.more_info ? > It disables the Cookie Manager button. (legacy of Netscape) So? This is mozilla now, not Netscape. So it should be removed. > > Why did you remove 'Ask for each cookie' from 'Cookie Acceptance Policy'? > > What exactly is 'Ask for each cookie' now? > > removed from what? That sentence doesn't parse. Cookie prompts now allow the > choice of whether to accept as sent or limit to session, along with rejecting > outright. I agree that its not the best option, but of the different options > that were discussed, it was the best solution. Wasn't 'Ask for each cookie' part of "network.cookie.cookieBehavior"? Isn't 'Cookie Acceptance Policy' associated with "network.cookie.cookieBehavior"? C'mon. You simply killed a perfectly working feature. So there was/is a better option. > the disabling and the controls= bits make sense, the rest is just opinion, and > given that I worked this out with the module peers/owner and the primary > seamonkey UI owner, I think there's consensus that the rest is what we're going > with. Ok, it is an 'opinion', but this was not just my personal opinion. We ask a bunch of people in our office (250) so there's more to come. We're not done yet. Hey, why is it that mozilla developers like you don't XUL to its full extend? I.E. why don't you use a broadcaster and observers, instead of element.disabled = [true/false]? IG: I also wonder why there isn't a general order for XUL attributes for mozilla, that would make reading XUL code easier. I know that it isn't necessary, but still. Also, why does developer A use 'someid' and developer B "someid". I'm here four years, and still learning, but also keep wondering where the heck all this inconsistency is comming from...but I keep smiling :-)

> Wasn't 'Ask for each cookie' part of "network.cookie.cookieBehavior"? > Isn't 'Cookie Acceptance Policy' associated with "network.cookie.cookieBehavior"? > C'mon. You simply killed a perfectly working feature. So there was/is a better > option. What feature was removed? to prompt before accepting a cookie? it's still there. In what internel pref it is implemented isn't really something you have to worry about.

bug 64336 is the automatically accept session cookies, I've seen in on forums too. >Wasn't 'Ask for each cookie' part of "network.cookie.cookieBehavior"? >Isn't 'Cookie Acceptance Policy' associated >with "network.cookie.cookieBehavior"? >C'mon. You simply killed a perfectly working feature. So there was/is a better >option. no, it never was. You could always use prompts in conjunction with any of the cookieBehaviour settings. That pref remains COMPLETELY unchanged. The only thing I "killed" was the combination of N days and cookie prompts. mvl made several attempts at proposing a comprimise via a hidden pref in another bug (the N days bug) but no one responded so we didn't pursue it. Maybe ask questions and get straight information before you rush to conclusions.

Mike, I looked at the mozilla source code and found this: http://lxr.mozilla.org/seamonkey/source/extensions/cookie/nsCookiePermission.cpp#92 So 'Ask for each cookie' was, and still is, "network.cookie.warnAboutCookies" but has no pref UI, right? I hope I'm reading this correctly. Sorry if I missed anything but I was in Spain for a couple of weeks, so I didn't had time to keep me up to date because we had other more important work to do. For your info: I only returned Friday, hit by Salmonella and I'm typing this comment from my bedroom, not feeling all to well (: Sorry if I was rude, but that wasn't ment to be like that. /me cheers and sends Mike and Michiel a sixpack :-)

> Mike, I looked at the mozilla source code and found this: > http://lxr.mozilla.org/seamonkey/source/extensions/cookie/nsCookiePermission.cpp#92 look again. http://webtools.mozilla.org/bonsai/cvsblame.cgi?file=mozilla/extensions/cookie/nsCookiePermission.cpp&rev=&root=/cvsroot&mark=165-174#151 the string for that pref only exists so that it can be migrated on browser startup to the newer "network.cookie.lifetimePolicy" pref.

(In reply to comment #6) > look again. > the string for that pref only exists so that it can be migrated on browser > startup to the newer "network.cookie.lifetimePolicy" pref. Darn, this is what you get if you're feeling sick and not taking the time to do some real hunting. However, you still "killed" the combination of N days and cookie prompts. This feature removal is simply something we don't like. What do we need to do to get it back in? I know that voting doesn't work here so what else does? Mike/Michiel, we're happy with a hidden pref setting, more than happy, but we obviously missed something ;)

the feature was already busted badly, so killing it was more like humane treatment There was a suggestion to make the "allow for session" perm/prompt action limit to N hours, so if you wanted to make it 7 days, you could set the pref to 144. This was in the N days bug, which is where the discussion on that belongs.

Forgot one: > > > pref.advanced.cookies.disable_button.more_info ? > > It disables the Cookie Manager button. (legacy of Netscape) > So? This is mozilla now, not Netscape. So it should be removed. No, this needs to be kept around so people can disable this for users with lock_pref etc. Removing this would just piss the people off who are migrating from Netscape. Anyway, marking this WONTFIX for the parts we're not touching, moving the rest to Bug 239557

V/Wontfix.