Closed
Bug 378854
Opened 18 years ago
Closed 9 years ago
xulrunner creates mozilla profile dir
Categories
(Toolkit Graveyard :: XULRunner, defect, P5)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: wolfiR, Unassigned)
References
Details
xulrunner resp. every xul application creates an empty mozilla profile ($HOME/.mozilla on Linux and %APPDATA%\Mozilla on Windows) although application.ini defines different values and the application's profile is at the right place.
That's only a cosmetic issue but anyway reporting it.
Comment 1•18 years ago
|
||
Tracked where XULRunner creates "mozilla" directory.
XRE_main ->
ScopedXPCOMStartup::Initialize ->
NS_InitXPCOM3 ->
xptiInterfaceInfoManager::GetInterfaceInfoManagerNoAddRef ->
BuildSearchFilePath ->
AppendFromDirServiceList (NS_APP_PLUGINS_DIR_LIST) -> -> ->
nsAppFileLocationProvider::GetFiles (NS_APP_PLUGINS_DIR_LIST) -> -> ->
nsAppFileLocationProvider::GetFile (NS_USER_PLUGINS_DIR) ->
nsAppFileLocationProvider::GetProductDirectory
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/xpcom/io/nsAppFileLocationProvider.cpp&rev=1.64&mark=322-328,395-400#322
If XULRunner's plugin location is designed to be under "mozilla" dir
regardless of vendor string, this is just (nontheless) a *cosmetic* issue.
Otherwise, it seems to me an actual bug. Anyway, XPCOM's dirServiceProvider
behaves quite different from XRE's, as far as plugin location concerned.
BTW, I wounder there, in the world, exists a plugin installer which
installes files under %APP_DATA%/mozilla/plugins directory... ?
Comment 2•18 years ago
|
||
They do exist, and we should load the plugins from ~/.mozilla/plugins
The only bug here is that we create the directory: there is no need to create the directory if it doesn't already exist.
Comment 3•18 years ago
|
||
The creation was there from rev 1.1 |GetDefaultUserProfileRoot()|.
***
{{
399 ccarlen 1.12 if (NS_SUCCEEDED(rv) && !exists)
400 bzbarsky 1.47 rv = localDir->Create(nsIFile::DIRECTORY_TYPE, 0700);
401 dougt 1.54
402 ccarlen 1.18 if (NS_FAILED(rv)) return rv;
}}
Would it be as simple as replacing line 400 by a |return NS_SomeErrorCode| ?
(and "swapping" line 402 and 399...)
And checking that the creation happens somewhere else (if needed) ?
Comment 4•18 years ago
|
||
well, you could just skip that line altogether. The problem is going to be identifying all the places that magically rely on the directory creation taking place.
Updated•12 years ago
|
Priority: -- → P5
Comment 6•9 years ago
|
||
XULRunner has been removed from the Mozilla tree: see https://groups.google.com/forum/#!topic/mozilla.dev.platform/_rFMunG2Bgw for context.
I am closing all the bugs currently in the XULRunner bugzilla component, in preparation for moving this component to the graveyard. If this bug is still valid in a XULRunner-less world, it will need to be moved to a different bugzilla component to be reopened.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•9 years ago
|
Product: Toolkit → Toolkit Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•