176274 - Emusic Page fails to set cookie because user_pref("capability.policy.default.HTMLDocument.cookie.set", "noAccess");

Status: VERIFIED INVALID

(Core :: Networking: Cookies, defect)

Description

[Eric Liga]

This one may be hard to troubleshoot because it requires you to be logged in to
emusic with a valid account.  I'll attach the source for the page with the
problem  in hopes that that will be sufficient.  

The problem is that when the user clicks on the link to "turn on the Emusic
Download Manager" (which should use javascript to set a cookie), the cookie
doesn't get set.  I've opened up every permission I can think of (most obviously
the perm to allow js to set a cookie) and it still refuses.  Had to hand-edit
the cookie file to bypass this problem.  Ideas?

Comment 1

[Eric Liga]

Attachment: HTML page with the problem

Comment 2

[Tom Everingham]

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

Comment 3

[Eric Liga]

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.

Comment 4

[Stephen P. Morse]

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.

Comment 5

[Eric Liga]

Attachment: 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.

Comment 6

[Eric Liga]

Attachment: Cookie log file for event in question (part 2/3)

Comment 7

[Eric Liga]

Attachment: Cookie log file for event in question (part 3/3)

Comment 8

[Stephen P. Morse]

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.
   

Comment 9

[Suresh]

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!

Comment 10

[Eric Liga]

Attachment: 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.

Comment 11

[Eric Liga]

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.

Comment 12

[Eric Liga]

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.

Comment 13

[[e-mail]]

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.

Comment 14

[Eric Liga]

Attachment: 1.3 Final log of JUST hitting that page and clicking "Click Here"

Confirmed again that I'm not blocking javascript from setting or reading
cookies.  Once again adjusted settings to allow cross-domain cookies, confirmed
I wasn't blocking cookies for emusic.com and that there was no pre-existing
EMP_WRAP cookie.  Are there any perms I'm forgetting to open up?

Copied emusic address, set environment variables to log cookies, restarted
browser, went directly to affected page, clicked "Click Here" and it didn't
work.  Did generate 83K of cookie log, though.	Would it do any good for me to
install Venkman and try to watch the flow of the javascript?

For what it's worth, I have no idea why this happens to me but (evidently) not
others.  I can reproduce this (lots of cookie activity in the log but no
EMP_WRAP set) in NT4, Win2K, and Win98.  I uninstall and reinstall between
releases, but haven't nixed and recreated my profile data in quite a few revs. 
Could this be somehow related to a corrupt profile?  Any way the settings could
show JS perms for creating cookies but not be honoring them?

Comment 15

[Eric Liga]

Extracted out just the cookie-setting script and substituted a document.writeln
to make sure it was correctly reading the params and attempting to use a valid
string to set a cookie.  Looks right.

Switched back to the "document.cookie=" that the original document has and ran
it through Venkman.  Venkman returns

Exception ``Permission denied to set property HTMLDocument.cookie'' thrown from
function (null)() in [line in test file that attempts to set "document.cookie="].

So it looks like it IS denying it the right to create this cookie.  Through the
prefs interface, I've unset and reset the "allow javascript to read / set
cookies" flags, but it doesn't help.

Ideas?

Comment 16

[Darin Fisher]

-> dwitte

Comment 17

[[e-mail]]

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?

Comment 18

[Darin Fisher]

dwitte: i really don't know.. maybe.. cc'ing jst.. he might know =)

Comment 19

[timeless]

could you post your prefs.js file? i'm especially looking for caps prefs

Comment 20

[Eric Liga]

Timeless:  looks like you were dead-on.

user_pref("capability.policy.default.HTMLDocument.cookie.set", "noAccess");

Changing that pref fixed the issue.  That's a legacy pref somehow, though, isn't
it?  

For kicks, I backed up my bookmarks, uninstalled moz, nuked my profile, and
reinstalled it.  It's certainly not in the prefs.js by default.  Adjusting the
cookies settings ("originating domain only") seemed to generate a
network.cookie.cookiebehavior pref.  Playing with the javascript cookie
permissions generated a dom.disable_cookie_set pref.

So I'm going to tag this as invalid-- guess all 3 machines I'm seeing it on just
haven't had their prefs.js nuked and recreated in so long that they had legacy
cruft hanging around. 

But since we're on the subject of preventing this sort of issue, I'd like to at
least ask if there's either A) Some personal install / uninstall behavior I can
change to keep legacy prefs from biting me (I do invoke the moz "uninstall"
periodically to keep things clean, but I guess that wouldn't touch the prefs.js)
or B) Some bug I can follow that tracks these types of issues and is perhaps
working towards a way to prevent them?

Comment 21

[timeless]

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.

Comment 22

[Eric Liga]

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.

Comment 23

[[e-mail]]

hmm - just a thought - should this be something the installer takes care of
(checking for obsoleted prefs)?

Comment 24

[Eric Liga]

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.