with 20020924 Phoenix going to: http://gemal.dk/browserspy/cookie.html produces: Error: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMNavigator.cookieEnabled]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: http://gemal.dk/browserspy/cookie.html :: <TOP_LEVEL> :: line 263" data: no] works with mozilla...

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20020926 Phoenix/0.2 WORKSFORME

I see this too, with a linux build from today. Possibly related to some of the prefs destruction?

I see this using a brand new install of Phoenix 0.4 on WinXP + a brand new profile.

*** Bug 177682 has been marked as a duplicate of this bug. ***

Blake: the uncaught exception is that because the pref is not used/set in Phoenix? Then it could be a potential problem with other browser too...

*** Bug 173448 has been marked as a duplicate of this bug. ***

Henrik: Phoenix uses a different pref. What do you mean it could be a problem with other browser?

Comment on attachment 105017 [details] [diff] [review] correct patch r-hyatt

Comment on attachment 105017 [details] [diff] [review] correct patch you need to return NS_OK in the MOZ_PHOENIX section. sr=bryner with that change.

I was just thinking about browser that like Phoenix doesn't use the pref, will have the same problem. It could be a lot of IF DEF's...

fixed.

Henrik is right. If we're having to put MOZ_PHOENIX ifdefs to support a cookie pref in nsGlobalWindow (Why the _hell_ is there cookie stuff in nsGlobalWindow) we have an architecture problem that we need to actually fix instead of wallpapering over it (and abusing the fact that Phoenix is "not just another embeddor" or something). Just think about what would happen if _any_ other gecko-based browser tried to pull off this sort of shit.... would it be allowed in the tree? Of course not.

This is madness. Madness! If we go down this path then every embedder will want their own #ifdefs and the tree will go to hell in a hurry. Build a real cookie module interface for nsGlobalWindow to obtain the cookie pref from, if you must have it --- one that all embedders can use. But #ifdef MOZ_PHOENIX has to go.

should we reopen this or open a new bug?

hyatt says on IRC "let's work to get rid of this #ifdef". We can do that here or in a new bug, I don't care.

Since no one has said anything either way, we're doing it here.

Comment on attachment 105017 [details] [diff] [review] correct patch obsoleting patch that's no longer relevant.

I doubt that blake is going to be implementing new cookie interfaces. Who can own this?

i'll fix this up. we're going to have to unfork the phoenix/mozilla prefs in order to move cookies into necko (and thus make it a part of the GRE). we'll probably split the cookie prefs into two sets: core (which live in necko, and thus the GRE); and app-specific (which live in an nsCookiePermission module outside the GRE). comments welcome.

this is fixed. unforkage complete.

verified fixed 2003-11-09