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)
Tracking
()
VERIFIED
FIXED
M12
People
(Reporter: ckritzer, Assigned: jud)
References
()
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:
Updated•25 years ago
|
Status: NEW → ASSIGNED
Summary: Cookies appear to not be implemented on linux → [DOGFOOD] Cookies appear to not be implemented on linux
Target Milestone: M12
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?
Reporter | ||
Comment 2•25 years ago
|
||
Duh, yeah info on Mac & Win results would be good, huh?
This only happens on Linux.
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Comment 3•25 years ago
|
||
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.
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Comment 4•25 years ago
|
||
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.
Comment 5•25 years ago
|
||
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?
Updated•25 years ago
|
Status: REOPENED → ASSIGNED
Comment 7•25 years ago
|
||
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.
Updated•25 years ago
|
Summary: [DOGFOOD] Cookies appear to not be implemented on linux → [DOGFOOD] http cookies not working on linux release builds
Comment 8•25 years ago
|
||
Reflecting reality by changing the summary from:
"cookies appear to not be implemented on linux"
to:
"http cookies not working on linux release builds"
Comment 9•25 years ago
|
||
FYI: The registry file is persistent for release builds too. Rick, did you mean
to suggest otherwise.
Assignee | ||
Comment 10•25 years ago
|
||
it's persistent between runs, yes. but not between QA engineers blowing it away
between installs.
Comment 11•25 years ago
|
||
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
Updated•25 years ago
|
Assignee: morse → dp
Status: ASSIGNED → NEW
Comment 12•25 years ago
|
||
Ok I see it in my linux debug build as of 12/2 tree open. I will see what is up
with this.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 13•25 years ago
|
||
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).
Comment 14•25 years ago
|
||
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 ?
Assignee | ||
Comment 15•25 years ago
|
||
expires. hmmm. sounds plausible. dates obviously have platform dependent impls.
But release vs. debug. I don't buy it. I'm stumped.
Assignee | ||
Comment 16•25 years ago
|
||
*** Bug 20667 has been marked as a duplicate of this bug. ***
Comment 17•25 years ago
|
||
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.
Comment 18•25 years ago
|
||
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.
Comment 19•25 years ago
|
||
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.
Comment 20•25 years ago
|
||
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.
Assignee | ||
Comment 21•25 years ago
|
||
note that PR_LOG can be used in release builds now.
Comment 22•25 years ago
|
||
hey hey I was thinking of sitting in front of leafs machine, put printfs and
seeing what the heck is happening.
Assignee | ||
Comment 23•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: dp → valeski
Status: ASSIGNED → NEW
Comment 24•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 25•25 years ago
|
||
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.
Comment 26•25 years ago
|
||
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.
Assignee | ||
Comment 27•25 years ago
|
||
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).
Comment 28•25 years ago
|
||
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.
Comment 29•25 years ago
|
||
fix just checked in, will be seen in next batch of builds
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] → [PDT+] 12/7
Assignee | ||
Updated•25 years ago
|
Component: Cookies → Necko
Assignee | ||
Comment 30•25 years ago
|
||
cookies now work on linux release. changing component.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 31•25 years ago
|
||
this is sooo history!
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 32•25 years ago
|
||
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.
Reporter | ||
Comment 33•25 years ago
|
||
This is fixed? I still see the problem when submitting a form on bugzilla...
Reporter | ||
Comment 34•25 years ago
|
||
Ignore last comment. It falls under the IMADOOFUS catagory...
Assignee | ||
Comment 35•25 years ago
|
||
please open a new bug
Comment 36•25 years ago
|
||
Rendering problem filed as bug 21049
Comment 37•25 years ago
|
||
Bulk move of all Necko (to be deleted component) bugs to new Networking
component.
You need to log in
before you can comment on or make changes to this bug.
Description
•