44314 - Special directories are wrong for embedding apps

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect, P1)

Description

[Adam Lock]

The embedding chrome doesn't work in the ActiveX control because the URL is 
not being resolved to the correct file path. The file resolution is wrong 
because the RDF chrome files ("all-packages.rdf", "all-skins.rdf", etc.) are not 
being loaded when the current working directory is not the Mozilla bin 
directory. 

For example running from "m:\moz\embedding\browser\activex\tests\cbrowse\debug\"
means that Gecko looks for the chrome 
in "m:\moz\embedding\browser\activex\tests\cbrowse\debug\chrome". Since it isn't 
there, the RDF graph is not loaded and the chrome loader resorts to defaults. 
For example, when I type "chrome://embedding/browser/content/mini-nav.xul", it 
resorts to the "wacky default" behaviour and resolves it 
to "resource:/chrome/packages/core/embedding/browser/content/mini-nav.xul". My 
chrome is not in the core directory so it's not found and Gecko sits there 
forever. 

The "wacky" behaviour is decided here after failing to find the baseURL for a 
chrome URL: 

http://lxr.mozilla.org/seamonkey/source/rdf/chrome/src/nsChromeRegistry.cpp#454 

A nasty hack to prove this is the problem is to copy the whole chrome folder to 
the current process directory and watch it work properly. The winEmbed app would 
also suffer this problem if it were run outside of the Mozilla bin directory. 

The ultimate culprit for all this is the call made by 
nsChromeRegistry::GetInstallRoot into the nsSpecialFileSpec class to get the 
chrome directory: 

http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/src/nsFileLocations.cpp#46
3 

The code incorrectly uses the 
value 
nsSpecialSystemDirectory(nsSpecialSystemDirectory::OS_CurrentProcessDirectory) 
as the base directory and appends "chrome" to it. When the current process 
directory is not the Mozilla bin directory, the value is incorrect. It will be 
incorrect for many embedding apps. Worryingly, a lot of other stuff in this 
method also make the same mistake. 

What to do? Personally I think we need to change many of the case statements in 
this method to use nsSpecialSystemDirectory::Moz_BinDirectory as the base 
directory. I'm attaching a patch that demonstrates the fix just for the chrome 
case.

Comment 1

[Adam Lock]

Attachment: Patch demonstrates how the chrome special directory should be resolved. Other special directories should probably do something similar.

Comment 2

[sairuh (rarely reading bugmail)]

over to jrgm for qa, methinks...

Comment 3

[Chris McAfee]

over to valeski for a look.

Comment 4

[Judson Valeski]

-> conrad

Comment 5

[Conrad Carlen]

The fix for this is in progress.

Comment 6

[Judson Valeski]

-> beta3

Comment 7

[Conrad Carlen]

I have been working on replacing nsIFileLocator with nsIDirectoryService, for 
this bug as well as for other reasons. Checked in the first stage of the process, 
have the code for the second stage in hand. Should be done soon. 

Comment 8

[Judson Valeski]

changing to new email

Comment 9

[Conrad Carlen (not reading bugmail)]

re-accepted at new email

Comment 10

[lchiang]

per email with Jud, changing nsbeta3+ to nsbeta3- on all "embed" keyword bugs
since embedding changes will not be made in the mn6 branch. If you feel this bug
fix needs to go into mn6 branch, please list the reasons/user impact/risk and
nominate for rtm. Thanks.

Comment 11

[Conrad Carlen (not reading bugmail)]

Fixed. There are no users of nsFileLocations left. The replacement,
nsIDirectoryService, places application files relative to a directory which is
passed to NS_InitEmbedding. Additionally, the embedding app can pass an
nsIDirectoryServiceProvider to NS_InitEmbedding and customize any application
relative file location.