Closed Bug 378854 Opened 18 years ago Closed 9 years ago

xulrunner creates mozilla profile dir

Categories

(Toolkit Graveyard :: XULRunner, defect, P5)

x86
All

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.
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... ?
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) ?
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
Priority: -- → P5
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
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.