Closed
Bug 321359
Opened 19 years ago
Closed 19 years ago
Give embedders the easy ability to lock and use profiles
Categories
(Core Graveyard :: Embedding: GRE Core, defect)
Core Graveyard
Embedding: GRE Core
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.9alpha1
People
(Reporter: benjamin, Assigned: benjamin)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
38.66 KB,
patch
|
darin.moz
:
review+
|
Details | Diff | Splinter Review |
One of the major problems with embedding is that embedders typically have to statically link the profile-locking code. This is not very scalable and it means that directoryservice keys which are relative to the profile may not be set in all circumstances etc. This patch is relatively involved; it does the following things: * Unifies the embedding directory provider and the xre directory provider * Makes the XRE directory provider look for an embedder-provided profile location, this allows for "seamonkey-style" profile selection (profile is not selected at xpcom startup). * Adds XRE_LockProfileDirectory which allows embedder to use the latest profile-locking logic. I don't want to freeze nsIProfileLock yet so I made the out-param just an opaque nsISupports. * Adds XRE_InitEmbedding2 in which profile locations can be specified prior to XPCOM startup * Adds XRE_NotifyProfile which can be used to "start" a profile after XRE_InitEmbedding2 (this also will work for seamonkey-style profile selection).
Assignee | ||
Updated•19 years ago
|
Assignee | ||
Comment 1•19 years ago
|
||
Attachment #206726 -
Flags: review?(darin)
Comment 2•19 years ago
|
||
I think the documentation needs to clarify when XRE_NotifyProfile should be called. For example, it's not obvious if it is necessary to call it after calling XRE_InitEmbedding2. Also, how do I select a new profile? XRE_InitEmbeddding2 would seem to be the only way.
Assignee | ||
Comment 3•19 years ago
|
||
There were two basic profile-selection strategies that I was allowing for: 1) select profile before xpcom startup (apprunner-style) XRE_LockProfileDirectory XRE_InitEmbedding2 XRE_NotifyProfile 2) select profile after xpcom startup (seamonkey-style) XRE_InitEmbedding ** Do XPCOM stuff to find the profile, and set "ProfD" in a directoryserviceprovider XRE_NotifyProfile But looking at this a bit more we may not need XRE_InitEmbedding2 at all. If the embedder just passes in a directoryserviceprovider at startup that sets "ProfD" and optionally "ProfDS" then the xredirprovider can do the rest (the embedder will still need to call XRE_NotifyProfile after XRE_InitEmbedding).
Assignee | ||
Updated•19 years ago
|
Attachment #206726 -
Attachment is obsolete: true
Attachment #206726 -
Flags: review?(darin)
Comment 4•19 years ago
|
||
The simplification of removing XRE_InitEmbedding2 sounds good to me. Also, I think it would be good to document the use cases in the header file.
Assignee | ||
Comment 5•19 years ago
|
||
This is a bit more complicated because of some forwarding from nsXREDirProvider to the application dirprovider, but it actually works with the gtkmozembed patch that I'm going to post shortly in bug 299988.
Attachment #207622 -
Flags: review?(darin)
Assignee | ||
Comment 6•19 years ago
|
||
Please ignore the change to toolkit/library/Makefile.in
Comment 7•19 years ago
|
||
Comment on attachment 207622 [details] [diff] [review] Profile selection and locking for embedders, rev. 2 >Index: toolkit/xre/nsEmbedFunctions.cpp >+ if (++sInitCounter > 1) // XXXbsmedberg is this really the right solution? > return NS_OK; ... >+ if (NS_FAILED(rv)) >+ return rv; So, it seems like XRE_InitEmbedding can return failure, and then leave the process in a state where XRE_InitEmbedding cannot be called again (unless XRE_TermEmbedding is called). Usually, it is best to revert things back to the way they were before XRE_InitEmbedding was called if it is going to fail, but hmm... perhaps that would be overly complex and not worth the effort at this point in time. >Index: toolkit/xre/nsXREDirProvider.cpp >+ if (NS_FAILED(rv)) >+ appEnum = nsnull; >+ else if (rv != NS_SUCCESS_AGGREGATE_RESULT) { >+ NS_ADDREF(*aResult = appEnum); >+ return NS_OK; >+ } nit: use brackets around the if block since there is an else block? >+ * 2) Select a profile some time after calling XRE_InitEmbedding. In this case >+ * the embedder must installs a directory service provider which provides s/must installs/must install/ r=darin
Attachment #207622 -
Flags: review?(darin) → review+
Assignee | ||
Comment 8•19 years ago
|
||
Fixed on trunk. I've filed bug 323161 for the multi-initialization issues.
Comment 9•19 years ago
|
||
a small typo in the comment: + * 2) Select a profile some time after calling XRE_InitEmbedding. In this case + * the embedder must installs a directory service provider which provides + * NS_APP_USER_PROFILE_50_DIR and optionally installs -> install
Assignee | ||
Comment 10•19 years ago
|
||
Michal, that was already noted and fixed on checkin ;-)
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•