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.
give alerts, prompts, and other common dialogs default titles, if none
are passed in.
todo: put those defaults into a string bundle so ICP doesn't kill me.
DOM: getting rid of JS_GetContextPrivate wherever possible. Use static parent
links where we can. When we do need to find this info about the caller
we call a function that knows how to get that info rather than inline calls
to JS_GetContextPrivate. This is all required for calling DOM objects on
non-DOM JSContexts as we do via xpconnect.
XPConnect: basic refactoring work to disassociate wrappers from the JSContext
that was active when the wrapper was constructed. This allows for calling into
wrapped JS objects on the right JSContext and for proper grouping of wrapped
native objects so that they can share proto objects. This also allows for
better sharing of objects and lays the foundations for threadsafety and
interface flattening.
Also, xpconnect tests are reorganized and improved.
fixes bugs: 13419, 17736, 17746, 17952, 22086
r=vidur r=mccabe r=norris r=cbegle
a=chofmann
2.) WebShell now implements the new nsIScriptGlobalObjectOwner.
3.) WebShell supports GetInterface to nsIScriptGlobalObject.
4.) Documents no longer carry around a reference to nsIScriptContextOwner. Instead they hold on to a nsIScriptGlobalObject. nsIDocument::GetScriptContextOwner has now become nsIDocument::GetScriptGlobalObject(). Same change to the set methods.
Add checks to nsScriptSecurityManager::CheckCanListenTo that take
a principal and ensure that the currently executing script code
either is from the same origin as that principal or has the
UniversalBrowserRead privilege enabled. (chrome code has all
privileges enabled by default.) It's okay for the principal passed in
to be null. That just signifies a privileged window/document that only
can be listened to with privileges.
I added GetPrincipal/SetPrincipal methods to nsIEventListenerManager.
nsDocument::GetNewListenerManager sets a principal on the listener
manager when it creates one. Obviously there are other places that
create listener managers, but scripts seem to go through this one.
Another change is to save some memory usage. Currently I allocate an
array of PolicyType that is NS_DOM_PROP_MAX elements long.
Unfortunately, compilers appear to allocate four bytes for each
PolicyType, so the array takes around 2400 bytes. I've added changes
to use two bit vectors that should consume about 1/16 that space.
r=joki
There are also changes that push nsnull onto the JSContext stack when
entering a nested event loop.
r=jband
tbogard%aol.net
danm%netscape.com
morse%netscape.com
racham%netscape.com
pp%ludusdesign.com
waterson%netscape.com
radha%netscape.com
davidm%netscape.com
ftang%netscape.com
edburns%acm.org
rpotts%netscape.com
sspitzer%netscape.com
jband%netscape.com
leaf%mozilla.org
scc%netscape.com
warren%netscape.com
norris%netscape.com
colin%theblakes.com
jdunn%netscape.com