189685 - Allow cookieservice to run without access to the profile directory

Status: VERIFIED FIXED

(Core :: Networking: Cookies, enhancement)

Description

[timeless]

as part of xpcshell testing i need to be able to create and probe arbitrary
services without setting up a full environment. this would have allowed me to
detect that bug 137512 was fixed.

The change will not affect normal consumers.

Comment 1

[timeless]

Attachment: patch

Comment 2

[timeless]

(qa) steps to reproduce (and verify):
[linux] ./run-mozilla.sh ./xpcshell
[windows] xpcshell

js>
Components.classes["@mozilla.org/cookieService;1"].getService(Components.interfaces.nsICookieService)

current output:
uncaught exception: [Exception... "Component returned failure code: 0x80570016
(NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016
(NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: typein ::
<TOP_LEVEL> :: line 1"  data: no]

desired output:
[xpconnect wrapped nsICookieService @ 0xa29640]

(the number will vary).

Comment 3

[[e-mail]]

Comment on attachment 111974 [details] [diff] [review]
patch

Looks fine, r=dwitte. We have nullchecks in the cookie code for checking
whether the cookies have been read correctly; so this shouldn't affect
anything.

Comment 4

[timeless]

checked in

Comment 5

[benc]

timeless: this is a whitebox bug.

Is there any post-checkin xpc results you can put here so you can verify this
yourself?

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

post-checkin xpc results:
chb@frodo:~/mozilla/debug/dist/bin$ ./run-mozilla.sh ./xpcshell
Type Manifest File: /home/chb/mozilla/debug/dist/bin/components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
js>
Components.classes["@mozilla.org/cookieService;1"].getService(Components.interfaces.nsICookieService)
WARNING: Trying to set p, file
/home/chb/mozilla/modules/libpref/src/prefapi.cpp, line 1017
[xpconnect wrapped nsICookieService @ 0x80f51e8]
js>

so this bug is fixed, marking verified.

however, timeless: is that "trying to set p" line ok? should a bug be filed for it?