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)
Tracking
()
RESOLVED
FIXED
mozilla1.9.1a2
People
(Reporter: romaxa, Assigned: romaxa)
References
Details
Attachments
(1 file, 4 obsolete files)
1.31 KB,
patch
|
benjamin
:
review+
|
Details | Diff | 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 1•16 years ago
|
||
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-
Assignee | ||
Comment 2•15 years ago
|
||
Assignee | ||
Updated•15 years ago
|
Attachment #324284 -
Flags: review?(benjamin)
Assignee | ||
Updated•15 years ago
|
Attachment #293782 -
Attachment is obsolete: true
Assignee | ||
Updated•15 years ago
|
Attachment #324284 -
Flags: review?(benjamin) → review?(mpgritti)
Assignee | ||
Comment 3•15 years ago
|
||
This is attempt to request mProfileDir from external dirService provider.
Attachment #325926 -
Flags: review?(benjamin)
Assignee | ||
Comment 4•15 years ago
|
||
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)
Assignee | ||
Comment 5•15 years ago
|
||
Maybe instead !strcmp(aKey, NS_*_PROFILE_*_DIR) better to compare key with "Prof*"
Comment 6•15 years ago
|
||
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-
Assignee | ||
Comment 7•15 years ago
|
||
Attachment #325927 -
Attachment is obsolete: true
Attachment #330844 -
Flags: review?(benjamin)
Updated•15 years ago
|
Attachment #330844 -
Flags: review?(benjamin) → review+
Updated•15 years ago
|
Assignee: nobody → romaxa
Keywords: checkin-needed
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
Comment 8•15 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•