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)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.9alpha1

People

(Reporter: benjamin, Assigned: benjamin)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

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).
Blocks: 299998
Blocks: 299988
No longer blocks: 299998
Attachment #206726 - Flags: review?(darin)
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.
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).
Attachment #206726 - Attachment is obsolete: true
Attachment #206726 - Flags: review?(darin)
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.
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)
Please ignore the change to toolkit/library/Makefile.in
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+
Blocks: 323161
Fixed on trunk. I've filed bug 323161 for the multi-initialization issues.
No longer blocks: 323161
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Blocks: 323161
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
Michal, that was already noted and fixed on checkin ;-)
Depends on: 441979
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: