- fix bug 12954 "should throw when setting non-settable props".
- fix bug 13418 "xpconnect needs to be threadsafe".
I think I filled in the cracks. Tests would be nice :)
- fix bug 22802 "[MLK] XPConnect Leaks".
- fix bug 24119 "[MLK] Reminder about cleaning up maps".
- fix bug 24453 "xpconnect needs default security manager".
I also changed the code in DOM and caps to just install a default secman and
not install a secman for each JSContext.
- fix bug 24687 "xpconect should avoid resolve performance suckage".
Added (modified) patch from shaver to create my JSObjects with the
global object as the temporary proto to avoid losing lookup.
- hack for bug 24688 "runtime errors in wrapped JS are not made obvious"
Added a debug only printf. We still need a JSErrorConsole service for this.
- fix bug 16130 "createInstanace and getService can create wrappers around wrappers"
Fixing this one really entailed changing the semantics of nsIXPConnect::wrapNative
and nsIXPConnect::wrapJS to use common code in xpcconvert that deals with existing
wrappers and DOM objects (with their own schemes for wrapping and unwrapping).
So, I changed the callers because the params changed slightly and some callers
were doing more work than necessary given the new semantics.
- Continued in the crusade to replace manaual refcounting with nsCOMPtrs whenever
touching old code.
- Added myself as first contributor to xpconnect files (vanity prevails!)
- Added new copyright header on some files that were missing it.
- Added some API comments.
- Converted nsXPCWrappedJS to implement nsIXPConnectWrappedJS via MI rather than
the old loser scheme of the nsIXPConnectWrappedJSMethods tearoff object.
- added DumpJSStack as globals to xpconnect and DOM dlls to be callable from
debuggers. I have ideas on how to improve and expand this support soon.
r=mccabe
858 [Feature] JavaScript auto-disable per-domain RFE
13023 Users must be able to disable Java and JavaScript (for JS in mail)
21923 Executing functions in "chrome:" protocol - #2.
r=mstoltz
(Checked in with red on Mac; Wan-Teh says his changes are localized so
it shouldn't interfere with his fixing bustage.)
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
20257 unable to edit existing images in editor due to JS error
19933 JavaScript "window.location" core dumps in CAPS
Back out previous changes for enforcing security on listeners and go with a
simple restriction of access to the method for adding listeners.
r=mstoltz
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
and efficiency.
Tighten checks on document properties and node properties. Should resolve
several bugs:
18965 document.firstChild vulnerability
19043 document.childNodes vulnerability
19044 document.lastChild vulnerability
r=mstoltz
17977 [DOGFOOD] Reading documents using document.body
17538 document.lastModified is exposed
17537 document.images vulnerabilities
16036 [DOGFOOD] document.Element exposes the DOM of documents from
15757 [DOGFOOD] Injecting JS code using setAttribute and getElemen
15550 Injecting text in documents from any domain using createText
15067 [DOGFOOD] getElementsByTagName() allows reading of arbitrary
* Create an array of dom property policy types and initialize it when the script security manager is created.
* Move some implementation code to a new shared implementation base class.
* Implement privilege enabling, disabling and reverting
* Implement stack walking for checking privileges.
r=mstoltz@netscape.com
* Modify nsIPref to support security policy work.
r=neeti@netscape.com
14443 "Same origin" security policy may be circumvented using docu
14820 Fixing up the relationship between nsCodeBasePrincipal and n
14919 Crash in JS MM code
Reviewed by mstoltz, approved by scc.
norris%netscape.com
scc%netscape.com
brade%netscape.com
jband%netscape.com
mstoltz%netscape.com
waterson%netscape.com
jdunn%netscape.com
dougt%netscape.com
warren%netscape.com
buster%netscape.com
dmose%mozilla.org
tbogard%aol.net
law%netscape.com
kipp%netscape.com
beard%netscape.com
rjc%netscape.com
sfraser%netscape.com
mscott%netscape.com
briano%netscape.com
alecf%netscape.com
don%netscape.com
shaver%netscape.com
bruce%cybersight.com
cyeh%netscape.com
joki%netscape.com
gagan%netscape.com
mccabe%netscape.com
ramiro%netscape.com
arielb%netscape.com