Closed Bug 20477 Opened 25 years ago Closed 25 years ago

[DOGFOOD] http cookies not working on linux release builds

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
HP
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: ckritzer, Assigned: jud)

References

(
URL
)

Details

(Whiteboard: [PDT+] 12/7) 

Overview Description: When loading the test URL, the page returns information
claiming cookies are not enabled for the browser, along with steps on how to
enable them for NS4+ & MSIE4+.

Steps to Reproduce:
1) Launch Linux6 1999113008 mozilla
2) Load http://www.bankofamerica.com/state.cgi?section=online into the location
field


Actual Results: Page will load, with message @ the bottom stating their site
detected our browser does not have cookies enabled.

Expected Results: Page loads without the message about cookies not being
enabled.

Build Date & Platform Bug Found: Linux6 1999113008 mozilla

Additional Builds and Platforms Tested On:
	- MacOS86 1999113008 mozilla
	- WinNT 1999113012

Additional Information:
Status: NEW → ASSIGNED
Summary: Cookies appear to not be implemented on linux → [DOGFOOD] Cookies appear to not be implemented on linux
Target Milestone: M12
Whiteboard: [PDT+]
Putting on PDT+ radar.

ckritzer, please let us know if this happens on all platforms.  You tested Mac
and Win32, but what were the results?
Duh, yeah info on Mac & Win results would be good, huh?

This only happens on Linux.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Using a build from 1PM today, I do not see the problem.  Closing this out as
works-for-me.  If you are still seeing it, please reopen and I will investigate
further.
Status: RESOLVED → REOPENED
I am seeing this too.  It looks like there are some other cookie problems
with Linux but I don't have them all narrowed down yet.   Using build
1999120208.   Re-opening.
This is very strange.  It definitely worked for me when I tried it on linux
yesterday.  I am unable to try it today because of some difficulty I'm having
running the browser on a linux machine at Netscape from my laptop at home by
going over a dsl line.

For a sanity check I asked Chis Waterson to try this on linux and see what he
gets.  He also did not get the failure.  So what are tever and ckritzer doing
differently from Chris and me?
Resolution: WORKSFORME → ---
Clearing WORKSFORME resolution due to reopen.
Status: REOPENED → ASSIGNED
After lengthy discussions with Chris Kritzer, Tom Everingham, Jud Valeski, Rick
Potts, and Chris Waterson, we have concluded that the conditions for duplication
this bug are the following:

1. linux box (works fine on windows and mac)
2. release build (works fine on debug build)
3. site attempts to set an http cookie (works fine for javascript cookies)

If all these conditions are met, the cookie does not get set.

Rick Potts tried to had a suggestion that the difference in behavior
between release and debug builds might be caused by the registry file.
He said that the registry is persisten across runs in debug builds but not in
the release builds.  So to rule this out we deleted the registry file before
running the debug build.  It still worked.  So much for that theory.
Summary: [DOGFOOD] Cookies appear to not be implemented on linux → [DOGFOOD] http cookies not working on linux release builds
Reflecting reality by changing the summary from:

   "cookies appear to not be implemented on linux"

to:

   "http cookies not working on linux release builds"
FYI: The registry file is persistent for release builds too. Rick, did you mean
to suggest otherwise.
it's persistent between runs, yes. but not between QA engineers blowing it away
between installs.
What Jud said :-)  it's more likely that release builds get installed and run in
fresh directories...  With debug builds it's more likely that cruft is
lurking...

-- rick
Assignee: morse → dp
Status: ASSIGNED → NEW
Ok I see it in my linux debug build as of 12/2 tree open. I will see what is up
with this.
Status: NEW → ASSIGNED
I lied. I had a bug in other changes in my tree.

I dont see this in the linux debug build. I am making a release build.

The cookie that comes in is

Cookie : cookiecheck=enabled; path=/;
Expires: Sat, 04 Dec 1999 16:39:42 GMT (8 hours after access).
Did my release linux build and it works. So I am stumped. My tree has some
cookie releated fixes but I cant understand how they would have fixed this. I am
assuming that I havent found the right trigger to reproduce the bug.

Could this be something to do with the expires ?
expires. hmmm. sounds plausible. dates obviously have platform dependent impls.
But release vs. debug. I don't buy it. I'm stumped.
*** Bug 20667 has been marked as a duplicate of this bug. ***
Judging from http://www.webvan.com/ (see bug 16835), this was a regression that
started between 1999-11-23-08-M12 and 1999-11-24-08-M12 Linux builds.
OK, from what dp is saying, it is not an issue of release versus debug because
he could not reproduce it on his release build.  So it is a difference between
engineering release build versus build-team release build.  Well that's simple
to solve -- we'll send the final release from engineering rather than from build
team. ;-)

BTW, here's a major flaw in bugzilla.  I went to check on this bug this morning
by looking in my bug list.  It wasn't there and I didn't have the bug number.
So I had to do a lot of searching to find it.  Apparently yesterday dp assigned
it to himself (it was previously assigned to me).  And since I am not on the cc:
list, am not the reporter, and am no longer the assignee, I didn't even get
notified that this reassignment had occured (nor did I receive notification of
any of the other comments added to the bug report since then).  I'm not
complaining mind you, just pointing out a flaw in the bugzilla notifications
since in this case I was (unintentionally) silently removed.

Regarding dp's comment about having something to do with expires, see the
recent comments that I added to 15111.  That bug has to do with 4.x mac putting
a different value in the expires field from all the other 4.x platforms and all
5.0 platforms.  Don't think this is the case here at all, but just thought I
would mention it.
I think the best course of action is to wait for monday's release builds to show
up. If it doesnt work, work off their tree and see what the problem is. (printf
debugging).

Steve any other plan of attack.
None that I can think of.  My only concern is how to put printf statements into
their tree.  For one thing, there will be a one-day turnaround every time you
decide to add another print statement.  For another, it will print on every
browser that anyone downloads or builds for that day so you can't go overboard
with prints.  Perhaps you should control the prints with an environment
variable.
note that PR_LOG can be used in release builds now.
hey hey I was thinking of sitting in front of leafs machine, put printfs and
seeing what the heck is happening.
Blocks: 19126
I think (mannnnnn I'm hoping) I whacked this last night (by fixing an
un-initialized nsresult turned up by dp during a phone debug session). Please
test release builds tommorow am.
Assignee: dp → valeski
Status: ASSIGNED → NEW
I used leafs machine to test this. I was running with the un-init rv fix.

I found that with the 5.0 release build cookie code was getting a NULL cookie
when it asked necko for a cookie from the http header.

The baffling thing is why this bug shows up for release builds only. Anyway, I
think we are moving out more into necko territory.
Status: NEW → ASSIGNED
The server does a 302 redirect to test for cookie settings. My guess is that
re-directs are not firing onheaders to module listeners on linux release. why. I
have no clue.
I don't think this has anything to do with the redirects.  Cookie creation
doesn't seem to be working on Linux, period.  In the 11-23 build, I see "First
Last Prev Next" links on bugzilla bugs found through a query, and in the 11-24
build (and later) I don't.
I'm saying there are two bugs here. 302 redirect linux release problems, and
cookies in general (I believe I checked in a fix for the latter).
The bugzilla problem I mentioned above is not fixed in 1999-12-06-13-M12 Linux
mozilla.  There is no redirect between the query results and the bug form.
fix just checked in, will be seen in next batch of builds
Whiteboard: [PDT+] → [PDT+] 12/7
Component: Cookies → Necko
cookies now work on linux release. changing component.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
this is sooo history!
Status: RESOLVED → VERIFIED
verified fixed with 12/7 builds

cookies are set, verified by looking at cookie viewer and cookies.txt file
cookie test on slip are now working correctly also

message no longer comes up about cookies not being enabled

Note: there is a rendering problem with the initial bank of america page on
linux, it appears to you have to select the content using a big click and drag
to get the page to render, but then you can select your state and you are off
and running. I will investigate that, but this bug is fixed.
This is fixed?  I still see the problem when submitting a form on bugzilla...
Ignore last comment.  It falls under the IMADOOFUS catagory...
please open a new bug
Rendering problem filed as bug 21049
Blocks: 21564
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
No longer blocks: 21564
You need to log in before you can comment on or make changes to this bug.