This appears to be working for me. Your page set 3 cookies, 2 from emusic.com and one from mp3.com. Is that what you were expecting? Can you check that you don't have cookies disabled in the preferences? What build id are you using? tested on winNT, win2k - 2002102308
Build 2002102208 on win2k and Build 2002091014 on NT4 In both cases, my prefs are set to "Enable cookies from originating website only" and "prompt me". (Although I did try it set to no restrictions just to check.) Also confirmed that I didn't have emusic on my block list. E-music sets other cookies for me without any trouble and reads cookies just fine (once I hand-added the cookie, all was good). It's possible that the prefs displayed aren't accurately reflecting their actual states... I'll check the prefs.js file to confirm.
Could you attach a cookie log so we can see what is going on. See the comment about logging in extensions/cookie/nsCookies.cpp. Thanks.
Created attachment 104181 [details] Cookie log file for event in question (part 1/3) This is the section of cookie log involving my interaction with e-music. I log in, go to the account page, go to the "Download Manager" page, and try to turn the "download manager" on. The bit on the page for "request URL: http://www.emusic.com/my_account/emp_setting.html?emp_value=1" is where it is trying to set the EMP_WRAP cookie with a value of "1". Why emusic appears to be requesting cookies at an ABSURD rate is beyond me. Maybe that's related to the problem. I had to split the log into thirds (and mind you, this was for visiting 3 pages and that's it) in order to get Bugzilla to accept it. Hmm... I have "enable all cookies" and "ask me before storing a cookie" turned on and it fails to prompt me at any time during this sequence. I do see cookie prompts at other sites. So either the site or Moz itself is failing to set the cookie. I was able to reproduce this sequence on the two builds listed above as well as an older build of Moz on my 98 box at home.
Attachment #104183 - Attachment description: Cookie log file for event in question (part 1/3) → Cookie log file for event in question (part 3/3)
The cookie log shows that all cookies that the site is attempting to set are indeed being accepted by the browser. There are only two -- namely age_13 which has no value and VUS17 which has a very big value. Furthermore, I am seeing that you already have several cookies from this site (from a previous run) which are being sent to the site at each request. Try clearing all your cookies first and then repeating the test. I'd like to see the log when these cookies actually got set, and see if there were any other attempted cookie settings at that time which failed.
eric: any chance you can try this out with a recent build and generate a new cookies log file (after deleting all existing cookies as morse suggests in comment #8)? please be clear about what your cookie preferences are when you repeat the test. thx!
Created attachment 111710 [details] Cookie log Here's a cookie log for this problem in the 2003011604 build of Moz running under Win2k. As before, I deleted the cookie file, started up, and went to the page (by way of bugzilla). So there's some bugzilla cookies in there (plus anything on "check for updates" in my bookmarks) but should be otherwise clean. However, it ends up with a TON of entries. Still not sure why.
It's worth noting that you can tell it doesn't work by the fact that it reloads the page after attempting to set the cookie and the page is still offering to turn the download manager on. If it had been set correctly, it would have offered to turn the download manager off. Perhaps there's an issue with *changing* the cookie that doesn't happen if it's simply creating it. I'll try deleting the cookie and trying again.
Confirmed under 1.3 Final, Win2K. Is no-one else seeing this issue? I can reproduce it on multiple machines under multiple (win-variant) operating systems.
WFM 1.3/win2k, with a variety of cookie settings: works if the cookie isn't already set, and works for modifying the already-existing cookie. Eric, the site is using JS to set and get the cookie - and by the looks of your log, a bunch of cookies are being sent fine (although tons of times, as you said). the relevant cookie here is "EMP_WRAP", which curiously doesn't appear in your log anywhere (either set or sent). 1) can you check your JS permissions under Edit/Preferences/Advanced/Scripts & Plugins/"Create or change cookies" & "Read cookies"? I suspect you have the former option switched off, since we're seeing no log entries to set the EMP_WRAP cookie. 2) can you attach (yet another) log taken with 1.3 final, starting with an empty cookie file? it'd be nice if you could skip the bugzilla ones too; just copy-paste the link, close moz, delete your cookie file, then start it up and paste the link.
Assignee: morse → dwitte
the dom.disable_cookie_set pref is checked at http://lxr.mozilla.org/seamonkey/source/content/html/document/src/nsHTMLDocument.cpp#2300 notice that it returns NS_OK if the cookie has been blocked in this way - so afaics, this couldn't produce the exception you're seeing. so at this point, i'm very much doubting this is a cookie-specific problem. recommend you poke your java install somehow, although i'm not sure exactly what you'd need to poke, or how ;) darin: recommend reassignment to a JS guru; who would this be? component = Java API's for DOM?
dwitte: i really don't know.. maybe.. cc'ing jst.. he might know =)
could you post your prefs.js file? i'm especially looking for caps prefs
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
i'm glad my hint was decipherable and that it solved your problem, as to your question... uninstalling won't help, you're mostly stuck, you could create a new profile (tools>switch profile>manage profiles) every now and then but people don't like doing that (and many have very very old profiles), and it isn't fun. you could look through about:config periodically but you'd have no way of knowing if something there was really interesting. perhaps someone should write a xul app that fishes for dangerous preferences, it'd be pretty easy to maintain a list and have people use it as a trouble shooter.
Status: RESOLVED → VERIFIED
Summary: Emusic Page fails to set cookie → Emusic Page fails to set cookie because user_pref("capability.policy.default.HTMLDocument.cookie.set", "noAccess");
Yup. Two of the machines had their Moz profiles recreated at various times, but my home system's profile may very well date back into the M-milestones. Tracking Bug 123929 follows profile corruption bugs, but I couldn't find a bug relating to deprecated prefs that are still supported but no longer used. I do like your idea for a small troubleshooting utility to track this sort of issue down. I'd be willing to do the coding if someone can come up with a good way to generate the data it'll need. I'll create an RFE and post back here with the bug number.
hmm - just a thought - should this be something the installer takes care of (checking for obsoleted prefs)?
Profile Troubleshooter RFE filed as Bug 198464. Dan-- I think adding intelligent profile maintenance to Moz itself would be fantastic, but it would be an uphill battle to convince people that it was both needed and safe. Creating data files, figuring out update logistics, and getting some real-world testing done prior to lobbying for that step would go a long way towards convincing folks.
You need to log in before you can comment on or make changes to this bug.