Closed Bug 104047 Opened 23 years ago Closed 23 years ago

OS/2 only - dates are not saved in cookies.txt

Categories

(Core :: Networking: Cookies, defect)

x86
OS/2
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: bugzilla.mozilla.org, Assigned: mkaply)

Details

(Keywords: platform-parity)

Attachments

(1 file)

Mozilla 0.9.4 reduces the lifetime of cookies so that they 
expire in the next session. I have not selected the lifetime 
limit check box in the preferences!

I have tracked this down to a simple example:
-create x.html:
<html>
<script>
 document.cookie="a=1; expires=01-Mar-03 GMT";
</script>
test a
</html>

-create y.html
<html>
<script>
 document.cookie="b=1; expires=01-Mar-03 GMT";
</script>
test b
</html>

-start mozilla
-open x.html
 cookie manager shows cookie a with expiration 2003
-close mozilla
-start mozilla
-open y.html
 cookie managershows cookie b with expiration 2003 and cookie a 
with expiration at end of session.
-close mozilla
-look into cookies.txt: cookie a died.
Reporter: Please try a more recent build to see if that alleviates your issue:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip
(as always, be sure to delete your old Mozilla directory before installing the
new one)

Or, if you're not using Windoze, you can get a build here:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/

Also, in future, please use the Bugzilla Helper for filing bugs:
http://www.mozilla.org/quality/help/bugzilla-helper.html
(among other things, that automagically includes your OS and Build ID)
Works fine for me.  Closing out as WFM.  Reporter, if you are able to reproduce 
with a more-recent build, then please reopen this report.  Thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Don't have newer version available. I have 0.9.4 from 09 oct 
2001.
OS: other → OS/2
Hardware: Other → PC
I'm sorry! 
It's Mozilla/5.0 (OS/2; U; Warp 4; en-US; rv:0.9.5+) 
Gecko/20011009
morse: Maybe OS/2 only ?
Can someone else (tever?) reproduce this on OS/2.  I don't have an OS/2 to try 
it on.
OK, this is mindblowing.

This does happen and it does only happen on OS/2.

If anyone could point me somewhere, that would be great.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Confirming as OS/2 only.
Assignee: morse → mkaply
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: mozilla eats cookies → OS/2 only - cookie is reset to end of session
More info.

y.html is not needed.

Open x.html - look in cookie manager - confirm expire date

Close browser. Open browser. Look in cookie manager - date has been changed to 
expire at end of session.
Problem converting dates, invalid usage of date functions?
Dates are not getting saved correctly.

They get converted to 0.
Summary: OS/2 only - cookie is reset to end of session → OS/2 only - dates are not saved in cookies.txt
The line that writes the expire time to the file is the following line in 
nsCookies.cpp.

      PR_snprintf(date_string, sizeof(date_string), "%lu", cookie_s->expires);

Is there anything about that line that is invalid for os/2?
The issue appears to be time_t.

On OS/2 time_t is a float, so the printf fails.

Still looking.
Actually it's a double.

Man OS/2 sucks. I don't know what to do here except a platform #ifdef.

I wonder how much else is broke because of this?
The fix here is to cast to an unsigned long in the printf.

This is probably the "right thing" anyway because there is no guarantee that 
time_t is an unsigned long (althought it is everywhere else on the planet)
Comment on attachment 52986 [details] [diff] [review]
Cast the time_t to an unsigned long before printf just in case it's not an unsigned long

r=morse
Attachment #52986 - Flags: review+
Adding "pp" keyword.
Keywords: pp
sr=alecf
damn. OS/2 is wierd.
Comment on attachment 52986 [details] [diff] [review]
Cast the time_t to an unsigned long before printf just in case it's not an unsigned long

looks like this still needs sr. a=asa for checkin to 0.9.5 as soon as it gets another review.
Attachment #52986 - Flags: approval+
Alec - could you put your sr on the attachment for Asa's benefit?

And for everyone's benefit, some info about the time_t thing from someone that 
had talked to the compiler people in the past:

time_t is a type, and I believe that the implementation is unspecified and left 
up to the compiler vendor.  As an implementation dependent type (i.e. close to 
opaque), assuming anything about it's format is bad as folks are discovering.  A 
different hardware vendor, who wants to put mozilla on a new chip (Transmeta, 
ITANIUM, some new phone CPU when the phones become 6ghz and have 2gig static 
ram), might have the same kind of difficulties if they choose a 'native' type 
for time_t and the math that mozilla assumes is not appropriate (masks the wrong 
size or some such error...) ...  Truthfully, special attention should be paid in 
any implementation that mentions 'cross-platform' to everything in ANSI that 
says platform specific or unspecified implementation...
Comment on attachment 52986 [details] [diff] [review]
Cast the time_t to an unsigned long before printf just in case it's not an unsigned long

oops! sr=alecf
Attachment #52986 - Flags: superreview+
Ok, works for me now. Thanks, Mike!
Fix checked in
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Per reporter, verify fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: