xulrunner creates mozilla profile dir

RESOLVED INCOMPLETE

Status

P5
minor
RESOLVED INCOMPLETE
12 years ago
3 years ago

People

(Reporter: wolfiR, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
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.
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

12 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.
Blocks: 387553
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

11 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.
No longer blocks: 387553
Duplicate of this bug: 387553

Updated

6 years ago
Priority: -- → P5

Comment 6

3 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
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
(Assignee)

Updated

3 years ago
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.