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. > _______________________________________________ mozilla-embedding mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-embedding
