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.

over to jrgm for qa, methinks...

over to valeski for a look.

-> conrad

The fix for this is in progress.

-> beta3

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.

changing to new email

re-accepted at new email

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.

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.