Closed
Bug 49223
Opened 24 years ago
Closed 24 years ago
widget should initialize profiles
Categories
(Core Graveyard :: Embedding: GTK Widget, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla0.9
People
(Reporter: blizzard, Assigned: blizzard)
Details
Attachments
(3 files)
5.40 KB,
patch
|
Details | Diff | Splinter Review | |
8.78 KB,
patch
|
Details | Diff | Splinter Review | |
8.36 KB,
patch
|
Details | Diff | Splinter Review |
The Gtk embedding widget should initialize profiles at startup.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•24 years ago
|
Target Milestone: --- → mozilla0.9
Comment 1•24 years ago
|
||
Apparently (see http://galeon.sourceforge.net/faq.php #9) this blocks browsers based around the widget from saving cookies to disk.
Comment 2•24 years ago
|
||
It might not have to initialize profiles. The lightweight solution is to use a directory service provider which provides the same file locations as profile mgr. There is such code in the tree built as a static lib at modules/mpfilelocprovider/. There is an example of its use in the powerplant embedding sample which handles cookies, wallet, and such. See: http://lxr.mozilla.org/seamonkey/source/embedding/browser/powerplant/source/CBrowserApp.cp#204 for how it's done. Profiles are needed only if distict user identities are desired.
Comment 3•24 years ago
|
||
I've got cookies working in galeon with mpfilelocprovider. Because of the static library, I think it would be good to add an api to gtkmozembed to do it. The code is this (I'm not checking rv ... but can give an idea). dir is the directory where prefs will be stored. static NS_DEFINE_CID(kPrefCID, NS_PREF_CID); nsresult rv; nsILocalFile* file = nsnull; nsComponentManager::CreateInstance(NS_LOCAL_FILE_CONTRACTID, nsnull, NS_GET_IID(nsILocalFile), (void**)&file); file->InitWithPath(dir); nsMPFileLocProvider *locationProvider = new nsMPFileLocProvider; rv = locationProvider->Initialize(file, "galeon"); NS_WITH_SERVICE(nsIPref, prefs, kPrefCID, &rv); prefs->ResetPrefs(); prefs->ReadUserPrefs();
Comment 4•24 years ago
|
||
Man Marko, Thanks for the info , I was going nuts trying to find out why I get a linking Error when I do the same stuff and I did not realize it was due to the lib being static I also think this should be in GtkMozEmbed. Comments Crhis? Merry Christmas everyone btw.
Comment 5•24 years ago
|
||
(And this is also why it'd be nice to have the static libs in a mozilla-devel RPM...)
Comment 6•24 years ago
|
||
This make PSM works too (tested on galeon cvs + mozilla cvs + psm downloaded with mozilla). And with a few lines you can make the history works too (and couloured links).
Assignee | ||
Comment 7•24 years ago
|
||
Thanks for doing the research to figure out how to do this. I'll add the api call to gtkmozembed.
Assignee | ||
Comment 8•24 years ago
|
||
Assignee | ||
Comment 9•24 years ago
|
||
Conrad, can you review this patch for me, please?
Assignee | ||
Comment 10•24 years ago
|
||
Ramiro might be interested in this patch.
Assignee | ||
Comment 11•24 years ago
|
||
Assignee | ||
Comment 12•24 years ago
|
||
This patch doesn't use static nsCOMPtrs.
Comment 13•24 years ago
|
||
Chris, you don't need to addref or destroy the nsMPFileLocProvider. In nsMPFileLocProvider::Initialize(), it registers itself with directory service. Doing this causes directory service to create an owning reference to the provider. I let this be the only ref to it so, when directory service is released, the provider gets released. If you wanted to keep your own reference to it (not sure why) you should call nsIDirectoryService::UnregisterProvider() on it before destroying it.
Assignee | ||
Comment 14•24 years ago
|
||
I was keeping a reference to it because I thought that if I didn't I would either leak it or I would destroy it too soon. If I can just let it go then I'll whip up a new patch to do that. As for prefs, I think that I have to hang on to it so I can shutdown before the app exits.
Comment 15•24 years ago
|
||
as discussed with blizzard on IRC: you do have to shutdown prefs manually (to get the pref changes written to disk) and it doesn't matter if you actually hold a ref to it sr=alecf with conrad requested change (and of course without the accidental ENABLE_GNOME)
Assignee | ||
Comment 16•24 years ago
|
||
Assignee | ||
Comment 17•24 years ago
|
||
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•