238045 - Cookie manager of 1.7beta does not display stored cookies

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect)

Description

[WADA:World Anti-bad-Duping Agency]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316

Cookie manager of release version of Mozilla 1.7beta does not display stored
cookies (no stored cookie is displayed).
Cookie data are available and usable (cookies.txt contains all cokkies). 

Bonsai for
mozilla/extensions/wallet/cookieviewer/resources/content/CookieViewer.js says ;
> 03/09/2004 15:58	bug 234183 Cookie Manager cleanup for 1.7b
> 03/07/2004 00:25	bug 102269 Cookie Manager: Server Secure is unclear.
> 02/10/2004 15:41	Bug 220915 Cookie site list doesn't update when removing a
cookie with the blacklist option
> 02/03/2004 15:32	Bug 227019 Cookie sites is blank if opened from cookie icon

This seems to be regression of fix for bug 227019 caused by fix for bug 234183.
Is it intentional change for Bug 230933?
> Bug 230933 Allow for storing more cookie attributes by creating a new file

Reproducible: Always
Steps to Reproduce:

Comment 1

[Mike Connor [:mconnor]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316

WFM from the Cookie Sites icon and invoking from either Preferences or
Tools->Cookie Manager.  Are you getting javascript errors or anything that might
identify what may be occuring?  Also, one bug you mentioned doesn't even have a
patch, and is marked NEW, so that won't have anything to do with anything here.
 Please don't guess at what bugs may have led to a regression unless you have a
regression window or you can back out changes and have this work.

dwitte, mvl, either of you seeing this?

Comment 2

[WADA:World Anti-bad-Duping Agency]

Following are JavaScript errors on both 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316 (1.7
Beta Relase - Installer Build)
and Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040315 (Zip
build).
None of stored cookies was displayed on both builds.

1.When Tools/Cookie Manager/Manage Stored Cookies
> Error: uncaught exception: [Exception... "Component returned failure code:
0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIScriptableDateFormat.FormatDateTime]" 
nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame ::
chrome://communicator/content/wallet/CookieViewer.js :: GetExpiresString :: line
282"  data: no]

2.When close Cookie Manager window
> Error: kObserverService has no properties
> Source File: chrome://communicator/content/wallet/CookieViewer.js
> Line: 137

Note: 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040215 displays
stored cookies with no problem as Bug 227019 says - RESOLVED FIXED.

Comment 3

[R.K.Aa.]

*** Bug 238145 has been marked as a duplicate of this bug. ***

Comment 4

[Darin Fisher]

WORKSFORME

1- started a new profile using mozilla 1.6, browsed to some sites, and confirmed
presence of cookies using the cookie manager.

2- closed browser, and restarted mozilla 1.6, and double checked presence of
cookies.

3- launched mozilla 1.7b, and checked for presence of cookies.  found the same
set of cookies that were there when i was using mozilla 1.6.

Comment 5

[Darin Fisher]

FWIW, i was testing Linux builds under Fedora Core 1.

Comment 6

[Darin Fisher]

reporter: did you install 1.7b using the WIN32 installer or the WIN32 .zip file?
 if you used the WIN32 .zip file, then please be sure that you did not unzip it
on top of your 1.6 installation.

Comment 7

[WADA:World Anti-bad-Duping Agency]

Darin Fisher, ZIP build or installer bild is already written in Comment #2.

Problem probably depends on already saved cookies.txt contents.

With new profile and newly created cookies.txt, 20040316 build(1.7 Beta, release
& installer build) displayed stored cookies successfuly.
However, with my currently using cookies.txt, 20040316 build(1.7 Beta, release &
installer build) failed to dispay stored cookies due to JavaScript error
reported in Comment #2.
 
I'll check which cookies.txt entry is cause of the JavaScript error.

Comment 8

[Darin Fisher]

WADA: sorry, i missed that bit in your previous comment.  thanks for the
clarification.

Comment 9

[Michiel van Leeuwen (email: mvl+moz@)]

The error comes from:
http://lxr.mozilla.org/seamonkey/source/intl/locale/src/nsScriptableDateFormat.cpp#148which
indicates a weird expires value in your cookies.txt.
That doesn't take away the need to check for errors, so the call to
gDateService.FormatDateTime should be wrapped in a try block.

Comment 10

[Mike Connor [:mconnor]]

Could someone who does have this issue please attach a copy of the affected
cookies.txt?  We need to see what the busted value looks like, and see if we're
doing something bad in writing the value.  This would also affect actually
expiring the cookie in question at the appropriate time.

A band-aid is all well and good, but I'd rather not go with a band-aid unless we
have to do that.  The band-aid is easy, but it will lead to missing information.

Requesting blocking1.7 so we don't ship with this.  There's a number of options
to fix this, but we need to get some idea of what we're really looking at here.

Comment 11

[WADA:World Anti-bad-Duping Agency]

I've found that following 2 entries are the cause of JavaScript Error.

> .dell.com	TRUE	/	FALSE	253407484800	RPO	features=desktops
> www1.us.dell.com	FALSE	/	FALSE	253407484806	plwp	c=us&l=en&s=dhs&cs=19&css=lg

12 digits are written as expiration field.
All other entries have 10 digits expiration filed.
Removing of above 2 lines cleared problem.

Who wrote 12 digits expiration field?
My guess is that these cookies are written by server of dell.com via HTTP rquest.
Is it server's fault or Mozilla's falut?

Comment 12

[Michiel van Leeuwen (email: mvl+moz@)]

The way to set thos long-lifetime cookies seems to be to use the max-age
attribute. It isn't checked for anything, so you can put anything in it.
My suggestion would be to add a check for a max (hardcoded) lifetime of say 30
years in nsCookieService::AddInternal, so new cookies can't get that long
lifetimes, and cookies read from cookies.txt will be limited too. the limit is
just to be a consitency check, to not have illegal or weird expiry values. And i
don't think it will be a problem for most users :)

Comment 13

[Mike Connor [:mconnor]]

Additional note to what mvl said, we also want to make sure to limit the
lifetime earlier than setInternal if we're using prompts, otherwise the numbers
in the dialog and the cookie manager won't add up.  If we do it there, it'll
pass the lifetime check in AddInternal so we don't need to relimit it.

This is getting into dwitte-land I think.

Comment 14

[[e-mail]]

If we're going to limit it, I'd like to have some info on what other browsers
do. I have a testcase at http://moneypenny.stanford.edu/tests/test-expiry.html.
Can someone test this with IE, and see what lifetime it limits the cookie to?

Comment 15

[Felix Gudio]

I should clarify - I used the Win32 installer for 1.7b.  File was dowloaded 
3/19/2004 @ 22:11 Central Time (US) using GetRight5.  Install was overlaying 1.6.

Comment 16

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #15)

Felix Gudio, what do you want to clalify?
Release note recomennds clean install always.
( http://www.mozilla.org/releases/mozilla1.7b/installation.html )
See also Bug 234741 for problems on installation to non-empty directry. 

Comment 17

[Michiel van Leeuwen (email: mvl+moz@)]

(In reply to comment #14)
> If we're going to limit it, I'd like to have some info on what other browsers
> do.
Why bother? 30 years is long enough. And using the expires: header, all you can
get is expire somewhere in 2037 afaik, so it really won't cause any problems.
The only reason to limit is to prevent errors like this. (hmm, in 5 years, 30
years expiry means 2039, so still parsing problems)

Comment 18

[Mike Connor [:mconnor]]

Attachment: wallpaper patch

really, this should be unnecessary once we figure out a sane way of limiting
cookies

Comment 19

[[e-mail]]

confirming, targeting to 1.7. we'll want this "wallpaper" patch in for final -
regardless that it's not the proper fix, it's good practice, since we know that
function can fail.

Comment 20

[Michiel van Leeuwen (email: mvl+moz@)]

(In reply to comment #14)
> If we're going to limit it, I'd like to have some info on what other browsers
> do. I have a testcase at http://moneypenny.stanford.edu/tests/test-expiry.html.
> Can someone test this with IE, and see what lifetime it limits the cookie to?

I tried it in IE 6.0. For the lack of anything resembling a cookie manager, i
looked at the cookie files. There was nothing mentioning this cookie. After
restarting IE, the cookie was gone. So it seems IE doesn't understand max-age.

One thing i did notice: when i typed
javascript:document.cookie="testcookie=foobar;max-age=1000"
in the url bar, the testpage now tells me: 
document.cookie = "TestCookie=TestValue; testcookie=foobar"
It looks like IE sets another cookie. Seems to be case sensitive. What does
mozilla do? (Yes i know it isn't this bug, but before i forget it...)

Comment 21

[Mike Connor [:mconnor]]

Comment on attachment 144548 [details] [diff] [review]
wallpaper patch

while in theory, a nice string saying something useful like "Not in your
lifetime" might be better, I'm not that concerned.  Eventually we should do
something better with the dates so this isn't an issue.  Also, we're past
localization freeze so the empty field will have to do.

Comment 22

[Rich Painter]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040316

i uninstalled moz 1.6 then installed 1.7b with the win32 installer.  my profile
is in a non-standard location: D:\ETC\Mozilla\Profiles\Earthlink PEI\j9pnxj30.slt.

my cookies.txt appears to be fine but i have not performed detailed analysis.  i
had no cookie problems with moz 1.6 just prior to installing 1.7b.

when i open the 1.7b cookie manage the stored cookies and cookie sites are
empty.  i am unable to function with new sites that require cookie changes with
the manager.

Comment 23

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 144548 [details] [diff] [review]
wallpaper patch

Error checking is a good thing anyway :)

>+    var string = "";
consider changing that into something more descriptive.

r=mvl

Comment 24

[Mike Connor [:mconnor]]

richard, if you can attach your cookies.txt or email me a copy I can take a look

or, if you're getting the error reported in comment 2 I'm sure its the same 
error and you don't need to bother.

Comment 25

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 144548 [details] [diff] [review]
wallpaper patch

Please also port this patch to the prompt.

Comment 26

[Mike Connor [:mconnor]]

mvl: okay, although the prompt just shows blank already, but the exception in
the JS console isn't pretty :)

Richard mailed me a copy of his cookies.txt file which had the same weird Dell
cookie in place.  I wonder how many copies of that are out there?

someone needs to file a spinoff bug to handle insanely long cookie expirations
better :)

Comment 27

[[e-mail]]

i'll figure out what function is responsible for the error and file a followup
bug for that. in the meantime, the fix here (plus a fix for the prompt ;) will
be sufficient to close this bug out, methinks.

i consider lifetime limiting a last resort, but if we need to do that we'll file
a separate bug.

Comment 28

[Gulliver]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040316

Same problem here with MacOS X version 10.3.3!

The cookies are there anyway, because I when I run Mozilla 1.6 they display
correctly. Problem also occurs when launching Mozilla without going to any site.

Comment 29

[Mike Connor [:mconnor]]

Attachment: wallpaper patch w/port to prompts

Comment 30

[Gulliver]

(In reply to comment #28)
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040316
> 
> Same problem here with MacOS X version 10.3.3!
> 
> The cookies are there anyway, because I when I run Mozilla 1.6 they display
> correctly. Problem also occurs when launching Mozilla without going to any site.



Weird! On my second machine with almost exactly the same installations the
cookies show up properly.

Comment 31

[Gulliver]

(In reply to comment #28)
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040316
> 
> Same problem here with MacOS X version 10.3.3!
> 
> The cookies are there anyway, because I when I run Mozilla 1.6 they display
> correctly. Problem also occurs when launching Mozilla without going to any site.



Weird! On my second machine with almost exactly the same installations the
cookies show up properly.

Comment 32

[Darin Fisher]

Comment on attachment 144807 [details] [diff] [review]
wallpaper patch w/port to prompts

hmm.. seems like this code should be shared somehow.

if this is wallpaper for 1.7f, then what is the long term solution?

Comment 33

[Mike Connor [:mconnor]]

Comment on attachment 144807 [details] [diff] [review]
wallpaper patch w/port to prompts

darin, the real fix is to figure out why we're ending up with cookies set for
the year 123015 or whatever those Dell cookies were being set for.  I really
don't think they're intentionally setting cookies with expirations that long
deliberately.  dwitte, mvl, and I have also bounced around ideas for limiting
the lifetime for screwups like this.

Comment 34

[Michiel van Leeuwen (email: mvl+moz@)]

The real fix ofcourse would be to make FormatDateTime not die. It is supposed to
be 64bit safe, so just give out reasonable dates for long life cookies.

Comment 35

[chris hofmann]

Comment on attachment 144807 [details] [diff] [review]
wallpaper patch w/port to prompts

a=chofmann for 1.7

Comment 36

[Mike Connor [:mconnor]]

checked in 2004-03-30 16:38

as a note, this bug had a different symptom in 1.6 and earlier, it just wasn't
so obvious about it.

about sharing the code, when I deal with bug 226339 I intend to unify a lot of
the shared functions like this.

Comment 37

[WADA:World Anti-bad-Duping Agency]

2004033108-trunk/Win-2K(SP4) displayed my saved cookies.txt with no error.
However, exipires field of 2 cookies described in Comment #11 became blank.
Comment #23 by Michiel is apparantly ignored. 
> +    var string = "";
> consider changing that into something more descriptive.
Is descriptive words be so hard to implement?
Please note that some other cookie's expires field is already displayed as "at
end of session".

Comment 38

[Mike Connor [:mconnor]]

The reason I used a blank string was because we're past the deadline for string 
changes for 1.7.  In 1.8a we can look at adding some sort of string to describe 
this insanely long-lived cookie, but I'd rather someone fix FormatDateTime to 
actually return a date instead of throwing an exception.

Comment 39

[R.K.Aa.]

*** Bug 239983 has been marked as a duplicate of this bug. ***