allows us to modify that user's first start page.
28060. r= mccabe, a= jevering.
git-svn-id: svn://10.0.0.236/trunk@62325 18797224-902f-48f8-a5cc-f745e15eee43
a browser window, the right page (home, blank or last page visted) gets
loaded. clean up tasksOverlay.js, navigator.js and Ensure1Window()
use the browser's command line handler (remove duplicate code).
remove uri dispatching ui and js. r=mscott
git-svn-id: svn://10.0.0.236/trunk@61086 18797224-902f-48f8-a5cc-f745e15eee43
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)
git-svn-id: svn://10.0.0.236/trunk@60771 18797224-902f-48f8-a5cc-f745e15eee43
removing "calendar" from the appearance pref panel, there is no calendar in
5.0.
r=mscott
git-svn-id: svn://10.0.0.236/trunk@60015 18797224-902f-48f8-a5cc-f745e15eee43
and enumerator of nsISupportsStrings. go from that, to a progid, and then
do a create instance, and then QI to a nsICmdLineHandler.
r=alecf
git-svn-id: svn://10.0.0.236/trunk@59941 18797224-902f-48f8-a5cc-f745e15eee43
the next step is to remove mozilla/xpfe/AppCores from the tree, which I will
gladly do next.
r=alecf
git-svn-id: svn://10.0.0.236/trunk@59932 18797224-902f-48f8-a5cc-f745e15eee43
Explicitly disable floating-point exceptions on FreeBSD, to force conformance with IEEE-specified behavior that the JS engine depends on.
Thanks to saska@acc.umu.se for the patch, and especially to all the experts who contributed to the discussion of this issue on the 9967 report.
r=mccabe.
git-svn-id: svn://10.0.0.236/trunk@57341 18797224-902f-48f8-a5cc-f745e15eee43
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.
git-svn-id: svn://10.0.0.236/trunk@56916 18797224-902f-48f8-a5cc-f745e15eee43
