Closed Bug 408925 Opened 16 years ago Closed 15 years ago

XRE_InitEmbedding does not initialize properly profilelock and gDirServiceProvider

Categories

(Toolkit :: Startup and Profile System, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.1a2

People

(Reporter: romaxa, Assigned: romaxa)

References

Details

Attachments

(1 file, 4 obsolete files)

Attached patch Probably this is proper fix (obsolete) — Splinter Review
After calling 
XRE_LockProfileDirectory
XRE_InitEmbedding

gDirServiceProvider not initialized properly and some components like extensionManager cannot startup properly with broken gDirServiceProvider.
Attachment #293782 - Flags: review?(benjamin)
Comment on attachment 293782 [details] [diff] [review]
Probably this is proper fix

This is not correct. The call to XRE_LockProfileDirectory does not *set* the profile directory. What sets the profile directory is the application directory provider. nsXREDirProvider should ask the application directory provider for the profile directories before using the builtin ones... or perhaps ask once and cache it in the members it uses internally.
Attachment #293782 - Flags: review?(benjamin) → review-
Attached patch Another way to fix this problem. (obsolete) — Splinter Review
Attachment #324284 - Flags: review?(benjamin)
Attachment #293782 - Attachment is obsolete: true
Attachment #324284 - Flags: review?(benjamin) → review?(mpgritti)
This is attempt to request mProfileDir from external dirService provider.
Attachment #325926 - Flags: review?(benjamin)
Attachment #324284 - Attachment is obsolete: true
Attachment #325926 - Attachment is obsolete: true
Attachment #325927 - Flags: review?(benjamin)
Attachment #325926 - Flags: review?(benjamin)
Attachment #324284 - Flags: review?(mpgritti)
Maybe instead !strcmp(aKey, NS_*_PROFILE_*_DIR)
better to compare key with "Prof*"

Comment on attachment 325927 [details] [diff] [review]
One patch for GtkMozEmbed dir provider and XREDirProvider

>--- mozilla/toolkit/xre/nsXREDirProvider.cpp.orig	2008-06-16 09:16:18.000000000 +0300
>+++ mozilla/toolkit/xre/nsXREDirProvider.cpp	2008-06-20 08:28:21.000000000 +0300


>+  if (!mProfileDir) {
>+    nsCOMPtr<nsIDirectoryServiceProvider2> appP2(do_QueryInterface(mAppProvider));
>+    if (appP2) {
>+      PRBool per;
>+      appP2->GetFile(NS_APP_USER_PROFILE_50_DIR, &per, getter_AddRefs(mProfileDir));

1) you don't need to QI to nsIDirectoryServiceProvider2, just nsIDirectoryServiceProvider
2) Please assert that, if GetFile succeeded, "per" is true... if we can't persist the profile directory, all sorts of bad things could happen.
Attachment #325927 - Flags: review?(benjamin) → review-
Attached patch Comment 6 fixesSplinter Review
Attachment #325927 - Attachment is obsolete: true
Attachment #330844 - Flags: review?(benjamin)
Attachment #330844 - Flags: review?(benjamin) → review+
Assignee: nobody → romaxa
Keywords: checkin-needed
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
Landed: http://hg.mozilla.org/index.cgi/mozilla-central/rev/1b2644a57966
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1a2
Depends on: 486679
You need to log in before you can comment on or make changes to this bug.