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

VERIFIED FIXED

Status

()

Core
Networking: Cookies
--
critical
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: Martin Sch, Assigned: mkaply)

Tracking

({pp})

Trunk
x86
OS/2
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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)

Comment 2

16 years ago
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
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 3

16 years ago
Don't have newer version available. I have 0.9.4 from 09 oct 
2001.
OS: other → OS/2
Hardware: Other → PC
(Reporter)

Comment 4

16 years ago
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 ?

Comment 6

16 years ago
Can someone else (tever?) reproduce this on OS/2.  I don't have an OS/2 to try 
it on.
(Assignee)

Comment 7

16 years ago
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 → ---
(Assignee)

Comment 8

16 years ago
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
(Assignee)

Comment 9

16 years ago
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.
(Reporter)

Comment 10

16 years ago
Problem converting dates, invalid usage of date functions?
(Assignee)

Comment 11

16 years ago
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

Comment 12

16 years ago
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?
(Assignee)

Comment 13

16 years ago
The issue appears to be time_t.

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

Still looking.
(Assignee)

Comment 14

16 years ago
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?
(Assignee)

Comment 15

16 years ago
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)
(Assignee)

Comment 16

16 years ago
Created attachment 52986 [details] [diff] [review]
Cast the time_t to an unsigned long before printf just in case it's not an unsigned long

Comment 17

16 years ago
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

Comment 19

16 years ago
sr=alecf
damn. OS/2 is wierd.

Comment 20

16 years ago
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+
(Assignee)

Comment 21

16 years ago
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 22

16 years ago
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+
(Reporter)

Comment 23

16 years ago
Ok, works for me now. Thanks, Mike!
(Assignee)

Comment 24

16 years ago
Fix checked in
Status: NEW → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
(Assignee)

Comment 25

16 years ago
Per reporter, verify fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.