Closed
Bug 18633
Opened 25 years ago
Closed 25 years ago
Unable to set cookie or get cookie with Mac.
Categories
(Core :: DOM: Core & HTML, defect, P1)
Tracking
()
VERIFIED
FIXED
M14
People
(Reporter: desale, Assigned: scc-obsolete)
References
()
Details
(Whiteboard: [PDT+])
Attachments
(1 file)
|
1.32 KB,
patch
|
Details | Diff | Splinter Review |
Unable to set cookie or get cookie with Mac.
Either cookie is not properly set, or getting cookie value is broken. It happens
only on Mac.
I'm using Mac 9.0
BUILDS: 1999-11-11-09.
STEPS TO REPRODUCE:
1] Visit above specified URL. [Internal Only]
OR
1] Copy HTML code I'm providing. Save it as HTML file.
2] Open this HTML file with mozilla.exe with above specified builds.
3] As soon as you load page, you'll see one alert. Observe message on alert.
4] Click OK on this alert.
5] After loading page, you'll see one button "Show Cookie Value". Click this
button.
6] You'll see one alert. Observe message on alert.
7] Click OK on this alert.
EXPECTED RESULTS:
Alert should show message like this.
Cookie Value = Test Cookie Value [Which is cookie value after setting cookie]
ACTUAL RESULTS:
Alert should show message like this.
Cookie Value = null [Cookie value shows null]
TESTCASE CODE START:
<html>
<head>
<title>Cookie Test</title>
</head>
<SCRIPT LANGUAGE="JavaScript">
<!--
function setCookie(name, value, expires, path, domain, secure) {
var curCookie = name + "=" + escape(value) +
((expires) ? "; expires=" + expires.toGMTString() : "") +
((path) ? "; path=" + path : "") +
((domain) ? "; domain=" + domain : "") +
((secure) ? "; secure" : "");
document.cookie = curCookie;
}
function getCookie(name) {
var dc = document.cookie;
var prefix = name + "=";
var begin = dc.indexOf(prefix);
if (begin == -1)
return null;
var end = document.cookie.indexOf(";", begin);
if (end == -1)
end = dc.length;
return unescape(dc.substring(begin + prefix.length, end));
}
// -->
</SCRIPT>
<body onLoad="alert('Cookie Value = ' + document.workform.testhid.value);">
<FORM NAME="workform">
<INPUT TYPE="hidden" NAME="testhid" VALUE="">
<INPUT TYPE="button" NAME="testbut" VALUE="Show Cookie Value"
onClick="alert('Cookie Value = ' + document.workform.testhid.value);">
</FORM>
<SCRIPT TYPE="text/javascript">
var now = new Date();
now.setTime(now.getTime() + 365 * 24 * 60 * 60 * 1000); //cookie expires in one
year
setCookie("counter", "Test Cookie Value", now);
var result = getCookie("counter");
document.workform.testhid.value = result;
</SCRIPT>
</body>
</html>
TESTCASE CODE END:
|
||
Comment 1•25 years ago
|
||
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.
|
|
||
Comment 2•25 years ago
|
||
Prashant, could you confirm that this is still a problem? I can't seem to find a
Mac build tonight and, since the bug is fairly hope, I'm hoping it's fixed
itself. If it is fixed, please close it. Thanks.
|
Reporter | |
Comment 3•25 years ago
|
||
Vidur I tested it with M13 builds and I found one thing that if we try to set
cookie to cgi script then it does work.
Like there are some cookie testcases at
http://slip/projects/dogbert/test/web/internal/cookies/
and these testcases do pass.
But the testcase I provided still fails.
My testcases tries to set cookie through Javascript. So Setting cookie through
Javascript is not working.
|
|
||
Updated•25 years ago
|
Whiteboard: [PDT+] → [PDT+] 1 day, if I can find a Mac build
|
|
||
Comment 5•25 years ago
|
||
Well, I tried to debug this on a Mac with no luck. For whatever reason, I can't
seem to step into some of the code in COOKIE_GetCookie(). I'm passing this along
to the owner of cookies for further investigation - I've convinced myself that
the DOM invocation of the cookie code is correct.
Assignee: vidur → morse
Status: ASSIGNED → NEW
Whiteboard: [PDT+] 1 day, if I can find a Mac build → [PDT+]
|
Assignee | |
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M14
|
|
Assignee | |
Updated•25 years ago
|
Priority: P3 → P1
|
|
Assignee | |
Comment 7•25 years ago
|
||
Getting cookies works fine. Setting cookies usually works fine. However,
setting cookies that expire runs into trouble. Problem is: the date gets
converted incorrectly. For a nice string like "Tue, 13 Feb 2001 15:16:23 GMT", |
PR_ParseTimeString| returns 982077383. This number is supposed to be
microseconds since the epoch, but since that is barely 12 days worth of
microseconds, this seems incorrect. The cookie is expired before it is even
added to the list. That can't be good.
So, my analysis is that |PR_ParseTimeString| is broken on the Mac. Investigating
further into that; though now it just might be time to re-assign the bug into the
NSPR team.
|
||
Comment 8•25 years ago
|
||
Scott, according to your analysis, how do you account for the fact that cookies
set from http are supposedly working fine but javascript cookies are not? Don't
they both use the same code to parse the date?
|
|
Assignee | |
Comment 9•25 years ago
|
||
The HTTP code path is different. In that code path, we call |PR_ParseTimeString|
twice, once for the servers current time, once for the time it wants the cookie
to expire ... then we add that to the current time on the client machine. That
ends up making a cookie that expires in the future, but not very far in the
future.
An interesting thing to note about the wrong time given above is that it is off
by a factor of 1000. As suggested by <rginda@netscape.com> some platform
routines may return seconds instead of microseconds. That suggestion fits the
observed behavior.
<morse@netscape.com> has asked me to re-assign this bug into the NSPR group; but
my current understanding is they are extremely understaffed and not taking new
bugs ... so I'm going to look deeper and see if I can't come up with a real fix
and submit a patch with this bug to make it easier for them. Steve Morse is also
looking at at |PR_ParseTimeString| to help find the real problem.
|
|
Assignee | |
Comment 10•25 years ago
|
||
No. This isn't right somehow. |PR_ParseTimeString| is returning the right
number of microseconds. And this number is getting converted into seconds in |
cookie_ParseDate|, so seconds (not microseconds) must be the canonical form for
cookies. Still, the value is significantly smaller than other cookie expires
dates, but it adds up to the right date in seconds. Hmmm. I just watched it do
everything including add the cookie to the list, but saving cookies didn't write
the new cookie out to the file. What does this mean?
|
|
Assignee | |
Comment 11•25 years ago
|
||
Then, I see as I get the cookie, that this cookie is deleted during the search
because it is considered expired. What the hell is going on? Steve? Do you
have any clue what this is?
|
|
||
Comment 12•25 years ago
|
||
It means that you can now use the cookie viewer to see what the expiration
date/time is rather than having to calculate it by hand. Once the cookie is
added to the cookie list, the cookie viewer will display it. It's under
tasks/autofill/display-cookies.
|
|
||
Comment 13•25 years ago
|
||
One thing to be aware of is that the cookie expiration time is recorded as
seconds since 1-1-70 on all platforms. In 4.7 the mac used to record it as
seconds since 1-1-1900 instead (because I believe that was how the native clock
in the mac kept time) whereas the other platforms in 4.x used the 1-1-70
baseline. Could this be relevant here?
|
|
Assignee | |
Comment 14•25 years ago
|
||
That's what it is, Steve. The line
time_t cur_time = time(NULL);
at the top of |COOKIE_GetCookie| on the Mac is returning the time since 1900.
And it's always expired. The right fix might be to call |PR_Now| and then
convert it an unsigned long. What do you think?
|
|
||
Comment 15•25 years ago
|
||
Or we could subtract out the number of seconds between 1900 and 1970 (for
mac-only of course). That number is 2,208,988,800 -- I've already calculated
that in bug 15111.
|
|
Assignee | |
Comment 16•25 years ago
|
||
OK, you actually use the bad |time(NULL)| function in several places. Here's my
patch which appears to work. I replaced several cases so it definitely needs
review.
|
|
Assignee | |
Comment 17•25 years ago
|
||
|
|
||
Comment 18•25 years ago
|
||
OK, I presume that the PR_NOW() function on all platforms returns the current
time in microseconds since 1970 whereas time(NULL) on the mac reterns it as
seconds since 1900. Is that correct? In that case your change looks fine. You
might want to add a comment to your get_current_time routine that gives the
reason you are not using time(NULL) because someone looking at this code in the
future might be tempted to simplify it to use time(NULL).
Of course you also could have had get_current_time use time(NULL) and then ifdef
the mac and subtract out my magic number in that case. Then you wouldn't have
needed all the LL_ routines. But either way is fine, so go for it.
Thanks for finding this problem Scott.
|
|
Assignee | |
Comment 19•25 years ago
|
||
Fix checked in with "nsCookie.cpp" version 1.53
|
|
Assignee | |
Comment 20•25 years ago
|
||
FIXED
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
Reporter | |
Comment 22•25 years ago
|
||
Marked verified by mistake. Meant to verify other bug. reopening and again
marking it fixed.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
|
|
Reporter | |
Comment 23•25 years ago
|
||
Marking fixed
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•