Bug 43347
This was a patch submitted, I have reviewed it (r=rayw)
it provides a softer landing when problems occur in the
initialization. There is no difference in behavior if
the initialization was successful.
part of startup to advance a progress display, per bug 35866.
I did not get the code actually reviewed, but I discussed it, and tested it
for breakage. Other developers must register for the observer before it can
be ascertained whether it performs as advertized.
Added new functions to the registry for reading / writing byte arrays
of binary content and escaping registry keys that contain binary
content. Modified code which reads/writes location of dll or javascript
for components to use new ReadBytesUTF8/WriteBytesUTF8 and which uses
or reads the keys to use EscapeKey and UnescapeKey.
r=dveditz
Added a simple test to CreateInstance, similar to the existing test in
GetService in the service manager, to prevent instances from being created
during shutdown. We detected no calls to CreateInstance in normal code we
tested during shutdown. If such occur, the fix is NOT to back out the
check, but rather to eliminate the calls to CreateInstance either by
registering a shutdown observer which gets called just before the
shutdown, or creating the instance before shutdown.
r=scc
Bug 12817 no Autoreg (in optimized builds) unless xpinstall detects flag indicating install has happened or build number changed, r=dp, a=jar;
Bug 23859 add wstring API to nsIRegistry for profile manager/i18n, r=gayatrib, a=jar;
new version registry name for mozilla, bug 10533;
log now created by install wizards too, bug 26309;
downloaded file cleanup moved into manager, bug 24249;
scaffolding for bug 12817 and 12361 (conditional autoreg)
in so many different directories, that I think it's the best way.
I've pulled and clobber_all'd my tree and got
r=dp
on this checkin.
Here are the touched files:
M mozilla/embedding/browser/activex/src/control/MozillaBrowser.cpp
M mozilla/embedding/browser/activex/src/control/MozillaBrowser.h
M mozilla/js/src/xpconnect/shell/xpcshell.cpp
M mozilla/netwerk/protocol/res/src/nsResProtocolHandler.cpp
M mozilla/xpcom/build/nsXPComInit.cpp
M mozilla/xpcom/components/nsComponentManager.cpp
M mozilla/xpcom/components/nsIServiceManager.h
M mozilla/xpcom/components/nsServiceManager.cpp
M mozilla/xpcom/io/nsSpecialSystemDirectory.cpp
M mozilla/xpcom/io/nsSpecialSystemDirectory.h
M mozilla/xpcom/tests/TestBuffers.cpp
M mozilla/xpcom/tests/TestPipes.cpp
M mozilla/xpcom/tests/TestShutdown.cpp
M mozilla/xpcom/tests/windows/TestHelloXPLoop.cpp
M mozilla/xpcom/tools/registry/regExport.cpp
M mozilla/xpcom/tools/registry/regxpcom.cpp
M mozilla/xpinstall/stub/xpistub.cpp
M mozilla/webshell/embed/ActiveX/MozillaBrowser.cpp
M mozilla/webshell/embed/ActiveX/MozillaBrowser.h
M mozilla/webshell/tests/viewer/nsMacMain.cpp
M mozilla/webshell/tests/viewer/nsPhMain.cpp
M mozilla/webshell/tests/viewer/nsWinMain.cpp
M mozilla/webshell/tests/viewer/unix/gtk/nsGtkMain.cpp
M mozilla/xpfe/appshell/src/nsFileLocations.cpp
M mozilla/xpfe/bootstrap/nsAppRunner.cpp
The heart of this checkin is a change in the signature and symantics
of NS_InitXPCOM.
The new signature is
extern NS_COM nsresult
NS_InitXPCOM(nsIServiceManager* *result, nsFileSpec* binDirectory);
I filed a bug for this problem:
b=23157
The original manifestation of this bug was in mozilla/netwerk/protocol/res/src/nsResProtocolHandler.cpp It used the current process directory to find resources, which is not correct when the current process is not mozilla.exe.
I have added a new type to nsSpecialSystemDirectory, Moz_BinDirectory, and made nsResProtocolHandler use that value.
blakeross%telocity.com
disttsc%bart.nl
dbaron%fas.harvard.edu
warren%netscape.com
rayw%netscape.com
jband%netscape.com
kandrot%netscape.com
racham%netscape.com
conrad%ingress.com
mkaply%us.ibm.com
shaver%mozilla.org
sfraser%netscape.com
dp%netscape.com
sgehani%netscape.com
dveditz%netscape.com
dougt%netscape.com
edburns%acm.org
blizzard%redhat.com
shaver%netscape.com
scc%netscape.com
beard%netscape.com
fur%netscape.com