Closed Bug 20477 Opened 20 years ago Closed 20 years ago
[DOGFOOD] http cookies not working on linux release builds
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
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: 20 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.
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?
Clearing WORKSFORME resolution due to reopen.
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
Ok I see it in my linux debug build as of 12/2 tree open. I will see what is up with this.
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.
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.
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.
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
cookies now work on linux release. changing component.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
this is sooo history!
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
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.