|
I have a
related question on what classes/API's I should be using for
profile managment in Firefox Deerpark Alpha 2 release. My embedded application was using nsIProfile to access and set profiles using the below code. This worked fine when buiilding Mozilla 1.8.b1 and below, but doesn't work in Deerpark Alpha 2 when building "browser". I've attemted to change the code to use nsProfileDirServiceProvider instead of nsIProfile as the gtk_embed browser does, however I'm having the same problem as the previous post because I'm using nsEmbedString throughtout my code and nsProfileDirServiceProvider pulls in nsAString.h . Do I need to change all of my code to use nsDependentString instead of nsEmbedString or another workaround? Or should I be using the stuff in the toolkit directory that was referenced in this thread instead of nsProfileDirServiceProvider? //code snippet: nsCOMPtr<nsIProfile> profileService; profileService =do_GetService(NS_PROFILE_CONTRACTID, &rv); rv=profileService->ProfileExists(profileName,&profileExists); if(profileExists==PR_TRUE){ profileService->SetCurrentProfile(profileName); }else{ rv=profileService->CreateNewProfile(profileName,profilePath,nsnull,PR_TRUE); profileService->SetCurrentProfile(profileName); } "drumminj" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]... > Gonna dig this one up, as I have a related question. I'm embedding > using the 1.73 source. > > Unless I'm missing something obvious, An embedding application must > create and register a ProfileDirServiceProvider in order for web pages > to be able to store cookies. Be default, the cookie manager queries > for the default user profile directory(NS_APP_USER_PROFILE_50_DIR I > believe), which is not handled by the AppDirectoryServiceProvider. The > ProfileDirServiceProvider does provide this directory. How do you > recommend an embedding application address this issue with the current > source base? > > Bringing in nsProfileDirServiceProvider causes one to drag in > nsString.h, which ends up requiring nsAString.h, which will conflict > with nsEmbedString.h. This can be worked around, but I'm hoping > there's a better way. I need users to be able to log into a web portal > via the embedded client, so I need the server to be able to set > cookies. > > Thanks. > > J > > Benjamin D. Smedberg wrote: >> Kevin Ollivier wrote: >> >> >>> were somehow worked around and removed. And it looks like >> >>> nsProfileDirServiceProvider may already be fixed for Moz 1.8, so > if >> >> >> >> It is not frozen in any way, and it *will* break in the future. >> >> Profile handling for the new toolkit is much different than the >> >> current seamonkey code, and we are planning on embedders using the > new >> >> toolkit in a consolidated "libxul" form. >> > >> > Is there anywhere I can learn more information about this? >> >> Seamonkey is based around an "xpfe toolkit" built from the xpfe/ >> directory. The new toolkit rewrites significant parts of this >> functionality in the toolkit/ directory, and is the basis for the >> new-style apps such as firefox, thunderbird, NVU, and sunbird. We are > >> planning on building a single consolidated library with a good >> versioning story called "libxul". The goal is to have embedding >> customers (such as wxWindows/Epiphany/Eclipse) use only frozen >> interfaces. In order for this to happen, we need to identify all the >> non-frozen interfaces you are currently using and find a way to > freeze >> the functionality you need. >> >> One of the major problems with the existing > nsProfileDirServiceProvider >> is the hard-coded application-specific paths (see >> > http://lxr.mozilla.org/mozilla/source/profile/dirserviceprovider/src/nsProfileDirServiceProvider.cpp#291 > >> and following). It is almost certain that we will need to add more > file >> paths to this list as apps change, but if you statically link this > file >> into your embedding app, we can't do that. I don't have a good > solution >> yet, but I can guarantee that things won't stay as they are, it's > just >> not a maintainable solution. >> > |
