Doug Turner (:dougt) Reporter
	Description • 25 years ago

There seams to be some kind of evil dependancy between cookie that the rest of
the product.  If I remove the cookie component from the component directory and
delete my components.reg file, I am unable to launch mozilla.exe.

	Suresh Duddi (gone)
	Comment 1 • 25 years ago

Hey why is this M11. We need to fix this only if there is a possibility of
shipping without cookie.dll which is far fetched.

Nonethless, it would be good to understand why this is happening.

	Andreas Otte
	Comment 2 • 25 years ago

I remember that it is impossible to build mozilla without the cookie extension.
Should not be to hard to find that evil dependency ...

	Stephen P. Morse Assignee
	Comment 3 • 25 years ago

The evil dependency is in nsAppRunner.cpp, line 579:

  NS_WITH_SERVICE(nsICookieService, cookieService, kCookieServiceCID, &rv);
  // quiet the compiler
  (void)cookieService;
#ifndef XP_MAC
  // Until the cookie manager actually exists on the Mac we don't want to bail
here
  if (NS_FAILED(rv))
    return rv;
#endif // XP_MAC

Anybody know why we should want to bail out if the cookie dll doesn't exist?  If
I completely remove the code that is currently bracketed by "ifndef XP_MAC, the
browser starts up fine without a cookie dll.

	Stephen P. Morse Assignee
	Comment 4 • 25 years ago

Looks like valeski added the nsWithService(nsICookieService...) along with the
test for failure -- back in version 1.88 on July 19 (later dagley added the
ifdef for the mac, but that's not relevant).  Jud, can you give a code review
for removing the test for failure (i.e., removing all the lines between and
including the ifndef XP_MAC).  Thanks.

	Judson Valeski
	Comment 5 • 25 years ago

hmmm. I think I put this in there initially because the cookie module needs to
init itself w/ an observer api (which happens when the module is loaded,
hence the with service at app startup) (to receive header notifications)
*before* we do any HTTP transactions.

Removing the failure check is fine, but we should be init'ing cookies at
startup.

	Stephen P. Morse Assignee
	Comment 6 • 25 years ago

Checked in new version of nsAppRunner.cpp which fixes the problem.

	Simon Fraser [no longer active]
	Comment 7 • 25 years ago

Even if we do need to load cookies at startup, this should *not* be polluting
main(), or anything in nsApprunner.cpp. It should be in some Necko init code,
surely?

	Stephen P. Morse Assignee
	Comment 8 • 25 years ago

Agreed.  That's the topic of bug report 14889 as you know (you reported it).
All the current bug fix did was remove an erroneous error check on the
intialization.  And the fix for bug 14889, when it is made, will remove the
initialization from nsAppRunner.cpp as well.

	Judson Valeski
	Comment 9 • 25 years ago

No. cookies have nothing to do w/ necko. they are a seperate and independent
application specific module.

	Stephen P. Morse Assignee
	Comment 10 • 25 years ago

But necko is using the cookie dll when it sets the cookie line in the outgoing
http header and when it received  a set-cookie line in an incoming http header.
Furthermore, it is the only module that uses the cookie dll.  So it is more
reasonable for necko to initialize the cookie dll module than for nsAppRunner
to do so.

	Tom Everingham
	Comment 11 • 25 years ago

verified:  NT 2000012520