Closed Bug 238045 Opened 20 years ago Closed 20 years ago

Cookie manager of 1.7beta does not display stored cookies

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.7final

People

(Reporter: World, Assigned: mconnor)

References

Details

Attachments

(1 file, 1 obsolete file)

wallpaper patch w/port to prompts
3.95 KB, patch
darin.moz
: superreview+
chofmann
: approval1.7+
Details | Diff | Splinter Review 
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:
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?
Assignee: darin → mconnor
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.
*** Bug 238145 has been marked as a duplicate of this bug. ***
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.
FWIW, i was testing Linux builds under Fedora Core 1.
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.
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.
WADA: sorry, i missed that bit in your previous comment.  thanks for the
clarification.
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.
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.
Flags: blocking1.7?
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?

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 :)
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.
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 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.
(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. 
(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)
Attached patch wallpaper patch (obsolete) — — Splinter Review 
really, this should be unnecessary once we figure out a sane way of limiting
cookies
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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Summary: Cookie manager of 1.7beta does not display stored cookies (regression of Bug 227019?) → Cookie manager of 1.7beta does not display stored cookies
Target Milestone: --- → mozilla1.7final
(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 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.
Attachment #144548 - Flags: superreview?(darin)
Attachment #144548 - Flags: review?(mvl)
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 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
Attachment #144548 - Flags: review?(mvl) → review+
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 on attachment 144548 [details] [diff] [review]
wallpaper patch

Please also port this patch to the prompt.
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 :)
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.
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.
Attachment #144548 - Flags: superreview?(darin)

        Attachment #144548 -
        Attachment is obsolete: true

    
  

        Attachment #144807 -
        Flags: superreview?(darin)

    
    

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


    
    

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

        Attachment #144807 -
        Flags: superreview?(darin) → superreview+

    
    

    
  
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.

        Attachment #144807 -
        Flags: approval1.7?

    
    

    
  
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 on attachment 144807 [details] [diff] [review]
wallpaper patch w/port to prompts

a=chofmann for 1.7

        Attachment #144807 -
        Flags: approval1.7? → approval1.7+

    
    

    
  
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.
Flags: blocking1.7?

    
  
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED

    
    

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

    
    

    
  
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.

    
    

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

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: