Closed Bug 99286 Opened 24 years ago Closed 24 years ago

Unable to set cookies

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: moz-bugzilla2, Assigned: danm.moz)

References

Details

(Keywords: platform-parity, smoketest)

I'm running build 2001091103 on W2K. On any sites which are trying to set cookies (such as session cookies), they do not seem to be able to set cookies. I've tried the "Enable all cookies" setting, I've tried the "Enable cookies for the originating web site only" setting. Both with and without Warm me before setting a cookie and cookies are not getting set. This did not seem to be a problem with yesterday's build and only cropped up today it seems like.
I've had problems with 2001091003/WinNT and cookies on www.mozillazine.org
Also can't set cookies on many sites such as http://slasdot.org/ or http://www.geocrawler.com/mypage/
Severity: major → blocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sorry, completely forgot build: 2001091103 on Win2k.
Yeah I have the same problem. I can't get yahoo, redhotpawn or any other site that I use with cookies. My build is 20010911 on w2k. Where do you find the 03 part?
flyguy, Look at the title bar, it should mention {Build ID: 2001091103}. However, it's not so important, there're rarely more than 1 build per day for each platform.
Linux does not have this problem. I tried 2001-09-11-08 and bugzilla set a few cookies on me. I have "Enable cookies for originating web site only" set in Preferences. This was tested with a new profile. WORKSFORME with 2001-09-11-08 on Linux.
wfm too on Linux with build 2001091108.
wfm on MacOS with build id: 2001091108, set and unset is done correctly
Adding "pp" keyword.
Keywords: pp
dp, my nsCookieService::Init() routine is no longer being called. Is this because of something you did? I can confirm that this is failing on win-nt.
Status: NEW → ASSIGNED
*** Bug 99327 has been marked as a duplicate of this bug. ***
This is blocking me from using bugzilla as usual. I have to login for every comment I make (like this one)! Using Windows 98, 2001-09-11-03. Should this be a smoketest blocker?
Twalker, is this sufficent for holding the tree?
*** Bug 99343 has been marked as a duplicate of this bug. ***
This is a smoketest blocker and should hold the tree per Asa.
Keywords: smoketest
And it's still there in the release for 9-12 at 0653 hrs. I've all ready deleted it and had no intention of reporting it, though I am here now ...
some comments are about cookies, some passwords... are neither being remembered? I've had troubles with password manager from build to build with the same profile. Testing some more.
Since I use a new build everyday and passwords don't seem to be retained by the profile I use from one build to the next, first time entering bugzilla I had to enter my login info. Restarted and I'm having no problems with it be remembered. I expect as long as I use this build it wil be fine. But why aren't the passwords being retained from build to build? They used to.
I dont yet have a build to look at. Building... From what you say steve, looks like the Notifications from categories are not hitting. NS_CreateServicesFromCategory() should be triggered from nsHTTPProtocolHander::Init() and that should cause cookies to be initialized.
Passwords works fine for me. The login textfields are automatically filled with password and email, but the cookies aren't created/remembered. Not even after a reboot.
dp and I are working on this
Assignee: morse → danm
Status: ASSIGNED → NEW
Here's the patch: Index: mozilla/xpfe/bootstrap/nsNativeAppSupportWin.cpp =================================================================== RCS file: /cvsroot/mozilla/xpfe/bootstrap/nsNativeAppSupportWin.cpp,v retrieving revision 1.38 retrieving revision 1.39 diff -c -2 -0 -r1.38 -r1.39 *** nsNativeAppSupportWin.cpp 2001/09/10 23:48:07 1.38 --- nsNativeAppSupportWin.cpp 2001/09/12 17:56:40 1.39 *************** *** 924,950 **** --- 924,956 ---- startupLock.Unlock(); PRBool serverMode = PR_FALSE; GetIsServerMode( &serverMode ); + #if 0 + /* temporarily disabling to clear smoketest blocker 99286 + don't create an http protocol handler service before XPCOM is initialized + (danm for dp) */ + if ( !serverMode ) { // okay, so it's not -turbo HKEY key; LONG result = ::RegOpenKeyEx( HKEY_CURRENT_USER, "Software\\Microsoft\\ Windows\\CurrentVersion\\Run", 0, KEY_QUERY_VALUE, &key ); if ( result == ERROR_SUCCESS ) { nsresult res; nsCOMPtr<nsIHttpProtocolHandler> http ( do_GetService( kHttpHandlerCID, &res ) ); if ( NS_FAILED( res ) ) return rv; nsXPIDLCString appName; http->GetAppName( getter_Copies( appName ) ); nsCString fullValue; fullValue.Assign( appName ); fullValue.Append( " Quick Launch" ); result = ::RegQueryValueEx( key, fullValue, NULL, NULL, NULL, NULL ); ::RegCloseKey( key ); if ( result == ERROR_SUCCESS ) SetIsServerMode( PR_TRUE ); } } + #endif return rv; } PRBool nsNativeAppSupportWin::InitTopicStrings() { We've disabled code in nsNativeAppSupportWin that enabled -turbo mode if some registry entry was set. (This involved creating an HTTP protocol handler before XPCOM had been initialized, which was kind of messing things up.) I just opened bug 99371 about reinstating that functionality but hopefully in some slightly different fashion.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
In my case it was strictly the cookies not being accepted and this has been for the last 2 releases.
*** Bug 99373 has been marked as a duplicate of this bug. ***
I rebuilt xpfe with this patch (as checked in) and it did not fix the problem for me. My problem is that I have to re-logon to bugzilla every time I change a bug in the same session. I'm also still hitting the assertion on startup that XP_ComInit failed. Do I need to rebuild outside xpfe?
David this fixed it for us when we looked at it. The key symptom is the assert on startup. Can you attach stack trace for your assert.
I don't have a assert on start-up, but some (not all see comments on bug 99373 ) cookies don't get set. It has something to do with the fact that not the whole domain, but only the major part of it is used to set the cookie (.yahoo.com instead of groups.yahoo.com). I also tried the rebuild, and the problem still exists for me... reopen?
I would guess so. I dont get the assert and cookies are working (havent tested throughly or anything). If the issue is "some cookies not set" then this should get reopened and assigned to steve morse <morse@netscape.com>
Note that "building in xpfe" does not build *all* of xpfe. xpfe/bootstrap, where this lives, is now built separately at the end (because of the static build changes)
I tried a lot of sites, and sites that supply a complete domain name eg on my own sidebar ( http://home.student.utwente.nl/j.houwing/mozilla/sidebar/tweakerssidebar.html ) the full "home.student.utwente.nl" domain is supplied. And the cookie get set (and if you have dialogs turned on the cookie dialog asks for permission. and with groups.yahoo.com only the top level and the company name are supplied ( .yahoo.com ) with the 10 sept. build it still asks to set this cookie and all is well, but with the 12 sept build no questions, no cookies. This can best be tested with the ask for every cookie turned on, as you can see if anything is changed or not.
Don't reopen and reassign. That would just be morphing the bug. The original symptoms were corrected and fixed. If there is something else broken, then please open a new bug report and clearly state the new symptoms. Thanks.
reopened bug 99373 for this. It was describing whatI stated above
rebuilding all fixed the assert and the cookie problem for me.
*** Bug 99425 has been marked as a duplicate of this bug. ***
Is it possible that the solution posted for this bug causes mozilla not to exit after the last window is closed? I tried yesterday's build without your patch, and tried it with your patch (and with the 13 september build) and now mozilla and in the last two mozilla won't reall exit and needs to be killed using the task manager before it can be started again...
verified: Win2k build 2001111303
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.