Closed Bug 439384 Opened 12 years ago Closed 10 years ago

"profile-do-change" event does not cause cookie table reload

Categories

(Core :: Networking: Cookies, defect)

x86
Windows XP
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: mikeperry.unused, Unassigned)

References

()

Details

In the migration to using sqlite for the cookies file seems to have broken the ability to signal the cookie manager with "profile-do-change" to cause a reload from disk. It does look like there is code in nsCookieService::Observe that does attempt to re-init the cookie database, but I'm not sure at a glance what is wrong with it. Perhaps it is still caching a connection to the old cookie database?

I ran into this bug while testing the cookie jar functionality with Torbutton on Firefox 3:
https://tor-svn.freehaven.net/svn/torbutton/trunk/src/components/cookie-jar-selector.js
but I'm wondering if it is possible this breaks other functionality as well (switching between profiles and such).

At any rate, this can be tested with the Torbutton snapshot xpi at 
http://fscked.org/transient/firefox/torbutton-1.2.0rc2-dev.xpi (sha1sum 823d3e7028d87faf1aebef551a3813d33bdce136). You don't need Tor installed, just acquire some persistent cookies and toggle the button twice. In Firefox 2, those
cookies persist after the return to "non-tor" state, but are gone in FF3 (despite the sqlite file being updated and the cookie service signaled).
Looks to me this could be a regression from bug 230933 then.
Blocks: 230933
Component: Places → Networking: Cookies
Product: Firefox → Core
QA Contact: places → networking.cookies
Version: 3.0 Branch → Trunk
please fix this :)
Please fix this bug.  It is cumbersome to have to manage the cookies manually when using tor.
Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html.  Comments asking for this to get fixed are non-constructive - this is what voting is for.
it should get reinited per
http://mxr.mozilla.org/mozilla/source/netwerk/cookie/src/nsCookieService.cpp#470

which will drop the existing ref to the db and open a new one. however if something else is holding refs to the connection, it may not close and thus the new one may fail to open... or something like that.

reporter, if you have the ability to roll a build and test that throwing a close statement in there fixes this, that'd be helpful to know.
so, i've looked into this and the profile-before-change/profile-do-change bits seem to be working fine - the file's getting reloaded and read in.

i'm guessing tor was copying the cookies.sqlite file after a profile-before-change and then copying it back and forcing a reload via profile-do-change (though looking at https://tor-svn.freehaven.net/svn/torbutton/trunk/src/components/cookie-jar-selector.js it looks like it now uses an xml format). is this the case? there's no guarantee the db is closed after a profile-before-change, which might be the problem. (as would trying to copy over an open file.)
Yes, you're right. Using the observer events was the wrong way to go. The current xml method is much cleaner and less prone to platform quirks.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.