378854 - xulrunner creates mozilla profile dir

Status: RESOLVED INCOMPLETE

(Toolkit Graveyard :: XULRunner, defect, P5)

Description

[Wolfgang Rosenauer [:wolfiR]]

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

[O. Atsushi (Torisugari)]

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

[Benjamin Smedberg]

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

[Serge Gautherie (:sgautherie)]

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

[Benjamin Smedberg]

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.

Comment 6

[Benjamin Smedberg]

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.