Closed
Bug 21792
Opened 25 years ago
Closed 25 years ago
[DOGFOOD] Site is unable to set cookies on fresh install. Changing prefs doesn't help,
Categories
(Core :: Networking: Cookies, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
M12
People
(Reporter: mwitbrock, Assigned: morse)
References
()
Details
(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 my.lycos.com or my.yahoo.com when user login is attempted. Presumably it won't take cookies from anyone. Attempts to toggle the cookie prefs have no effect.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
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
Assignee | ||
Comment 1•25 years ago
|
||
I have a tree that I pulled yesterday at around noon and it is setting cookies just fine. I went to my.lycos.com 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?
Assignee | ||
Comment 2•25 years ago
|
||
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.
Assignee | ||
Comment 3•25 years ago
|
||
Yep, that's the culprit. When I grabbed Judson's change to nsHTTPChannel.cpp and returned to my.lycos.com, no cookie is being set. However home.netscape.com is setting cookies correctly, but that is using javascript to do so. So not all cookies are broken, only http-header cookies.
Reporter | ||
Comment 4•25 years ago
|
||
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 my.lycos.com, 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).
Assignee | ||
Comment 5•25 years ago
|
||
Another way to see what is happening is to use the cookie viewer. From the menu select edit/wallet/display-cookies.
Comment 6•25 years ago
|
||
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 :).
Comment 7•25 years ago
|
||
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 my.yahoo was not working. The only thing I can't explain is the problem Steve is seeing. I used my.lycos.com, my.aol.com, my.yahoo.com, and my.netscape.com 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.
Assignee | ||
Comment 8•25 years ago
|
||
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.
Assignee | ||
Comment 10•25 years ago
|
||
Nope, it's not fixed. My build just finished and I retried it. Still no cookies from my.lycos.com. I'll try backing out Judson's change now and see if cookies come back.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Comment 11•25 years ago
|
||
OK, there was some confusion here. Let me explain. The bug report merely mentioned going to my.lycos.com. 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 my.lycos.com 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 my.lycos.com 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. I
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 12•25 years ago
|
||
marking as verified
You need to log in
before you can comment on or make changes to this bug.
Description
•