Closed Bug 21792 Opened 21 years ago Closed 21 years ago

[DOGFOOD] Site is unable to set cookies on fresh install. Changing prefs doesn't help,


(Core :: Networking: Cookies, defect, P3, major)

Windows NT





(Reporter: mwitbrock, Assigned: morse)




(Whiteboard: [PDT+])

Build 1999121408 of Mozilla (with which I don't seem to be able to sucessfully
log in to bugzilla) will not successfully accept cookies from or when user login is attempted.  Presumably it won't take cookies
from anyone.  Attempts to toggle the cookie prefs have no effect.
Summary: Site is unable to set cookies on fresh install. Changing prefs doesn't help, → [DOGFOOD] Site is unable to set cookies on fresh install. Changing prefs doesn't help,
Target Milestone: M12
I have a tree that I pulled yesterday at around noon and it is setting cookies
just fine.  I went to and got a cookie from doubleclick with the
name of "id" and the value of "A".  Was this working properly for you on
yesterday's build and just started failing today?

Judson, did you change anything in the cookie-notification path yesterday?
In particular, it looks like Judson's fix for bug 21197 (which he checked in at
3PM yesterday) could be the culprit.  I'll pull his changes into my build and
see if that caused my build to fail to set cookies.
Yep, that's the culprit.  When I grabbed Judson's change to nsHTTPChannel.cpp
and returned to, no cookie is being set.  However
is setting cookies correctly, but that is using javascript to do so.  So not all
cookies are broken, only http-header cookies.
It's strange,
When it tried to set the cookie for the initial login, the site complained that
it couldn't set the cookie.  However, now, when I return to, it is
behaving as if the cookie has been set.  Obviously this problem is not as
clear-cut as I had originally thought (I went back to the page, because I was
going to switch on cookie set notification in prefs, to see what was happening).
Another way to see what is happening is to use the cookie viewer.  From the menu
select edit/wallet/display-cookies.
This is a major regression. I'll back out my change from yesterday (someone
pressured me into checking it in :-| ). Tomato Tomato for broken cookies in m12.
Funny thing is it's either yahoo that's broken, or lycos :).
First of all, I'm the one that pressured jud to check this in :-)

Second of all, I don't see any problems at all using the 12/15 release build
which has the fix in it. The reporter is using 12/14 release which does not have
the fix, so I would expect my.lycos to not work, much as was not working.

The only thing I can't explain is the problem Steve is seeing.

I used,,, and and they were
fine, in addition to checking our standard http header tests.

Steve, this is assigned to you, so I won't mark it worksforme, but I don't
understand what could be wrong with your build.
Well the only thing "weird" about my build is that I dropped one of Judson's
file-changes from yesterday afternoon into a tree that I pulled yesterday at
noon.  Let me start with a completely fresh tree as of right now, pull and
build, and see what it does.  I've just started the pull.  Will report back as
soon as the build finishes.
Whiteboard: [PDT+]
Putting on PDT+ radar. But shouldn't this be marked Resolved/Fixed?
Nope, it's not fixed.  My build just finished and I retried it.  Still no
cookies from  I'll try backing out Judson's change now and see if
cookies come back.
Closed: 21 years ago
Resolution: --- → WORKSFORME
OK, there was some confusion here.  Let me explain.  The bug report merely
mentioned going to  It did not mention that from there you need to
click on the "My Lycos" link to get to the point where the cookie should be set.
So I was not doing that.  Instead I was stopping at the site.  And,
unfortunately, on that particular run there must have been an ad from
doubleclick and doubleclick was setting a cookie.  That is the cookie that I
saw.  Then when I back out Judson change and tried it again, I probably got to
the page with a different ad and it didn't go to doubleclick.
Hence no cookie was being set.  I erroneously concluded that the difference was
caused by the change that I backed out rather than the fact that the site was
serving up different content each time you visited it.\

Now that I understand the bug report better (paulmac explained to my what the
reporter really meant, rather than what he said), I tried again.  Both with and
without Valeski's fix, the cookie (real lycos cookie, not doubleclick cookie) is
being set.  So there is no bug here.  Marking as works-for-me since I can't
reproduce it, Judson can't reproduce it, and paulmac can't reproduce it.

If the reporter is still seeing a problem, please give a clearer set of steps
for reproducing it and reopent the report.

marking as verified
You need to log in before you can comment on or make changes to this bug.