Closed
Bug 439384
Opened 17 years ago
Closed 15 years ago
"profile-do-change" event does not cause cookie table reload
Categories
(Core :: Networking: Cookies, defect)
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).
Comment 1•17 years ago
|
||
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
Comment 2•17 years ago
|
||
please fix this :)
Comment 3•17 years ago
|
||
Please fix this bug. It is cumbersome to have to manage the cookies manually when using tor.
Comment 4•17 years ago
|
||
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.
Comment 5•17 years ago
|
||
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.
Comment 6•17 years ago
|
||
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.)
Reporter | ||
Comment 7•15 years ago
|
||
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: 15 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•