Closed Bug 104047 Opened 24 years ago Closed 24 years ago

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

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

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

Details

(Keywords: platform-parity)

Attachments

(1 file)

Cast the time_t to an unsigned long before printf just in case it's not an unsigned long
652 bytes, patch
morse
: review+
alecf
: superreview+
asa
: approval+
Details | Diff | Splinter Review
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: 24 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: 24 years ago → 24 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

Creator:
Created:
Updated:
Size: