Unable to set cookie or get cookie with Mac.




20 years ago
17 years ago


(Reporter: desale, Assigned: scc-obsolete)


Mac System 8.6

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+], URL)


(1 attachment)



20 years ago
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.

1] Visit above specified URL. [Internal Only]


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
6] You'll see one alert. Observe message on alert.
7] Click OK on this alert.


Alert should show message like this.
Cookie Value =  Test Cookie Value [Which is cookie value after setting cookie]

Alert should show message like this.
Cookie Value =  null [Cookie value shows null]


<title>Cookie Test</title>


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));

// -->
<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);">
<SCRIPT TYPE="text/javascript">
var now = new Date();
now.setTime(now.getTime() + 365 * 24 * 60 * 60 * 1000); //cookie expires in one
setCookie("counter", "Test Cookie Value", now);
var result = getCookie("counter");
document.workform.testhid.value = result;


Comment 1

19 years ago
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.

Comment 2

19 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.

Comment 3

19 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 

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.


19 years ago
Keywords: beta1

Comment 4

19 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]


19 years ago
Whiteboard: [PDT+] → [PDT+] 1 day, if I can find a Mac build

Comment 5

19 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
Whiteboard: [PDT+] 1 day, if I can find a Mac build → [PDT+]
scott could you help steve with this.
Assignee: morse → scc


19 years ago
Target Milestone: M14


19 years ago
Priority: P3 → P1

Comment 7

19 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

19 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?

Comment 9

19 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 

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.

Comment 10

19 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?

Comment 11

19 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

19 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 

Comment 13

19 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?

Comment 14

19 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

19 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.

Comment 16

19 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 

Comment 17

19 years ago
Created attachment 5255 [details] [diff] [review]
patch to fix cookie expiration problems

Comment 18

19 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.

Comment 19

19 years ago
Fix checked in with "nsCookie.cpp" version 1.53

Comment 20

19 years ago
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 21

19 years ago
Verified with 2000-02-14-09.

Comment 22

19 years ago
Marked verified by mistake. Meant to verify other bug. reopening and again 
marking it fixed.
Resolution: FIXED → ---

Comment 23

19 years ago
Marking fixed
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 24

19 years ago
Working fine now. Tested with 02-17.


17 years ago
Hardware: PC → Macintosh
You need to log in before you can comment on or make changes to this bug.