STEPS TO REPRODUCE: 1) Drop the attached testComponent.js file into your dist/bin/components 2) Start the browser 3) Load data:text/html,<img src="http://www.mozilla.org/images/mozilla-banner.gif">Test EXPECTED RESULTS: Image loads ACTUAL RESULTS: Broken image, indicating that the HTMLImageElement was not XPCNativeWrappered before being passed to the JS component. NOTES: I thought I fixed this in bug 337095, but I was wrong. The only reason it worked there is that the adblock code uses the subscript loader to load policy.js, and uses a chrome URI to point to it, so policy.js ends up with the system script flag set.

Comment on attachment 230757 [details] [diff] [review] Proposed patch >Index: js/src/xpconnect/loader/mozJSComponentLoader.cpp >=================================================================== >RCS file: /home/bzbarsky/mozilla/cvs-mirror/mozilla/js/src/xpconnect/loader/mozJSComponentLoader.cpp,v >retrieving revision 1.124 >diff -u -p -d -8 -r1.124 mozJSComponentLoader.cpp >--- js/src/xpconnect/loader/mozJSComponentLoader.cpp 10 Jun 2006 00:47:40 -0000 1.124 >+++ js/src/xpconnect/loader/mozJSComponentLoader.cpp 26 Jul 2006 17:27:27 -0000 >@@ -1115,16 +1115,24 @@ mozJSComponentLoader::GlobalForLocation( > nativePath.get()); > #endif > return NS_ERROR_FAILURE; > } > > // Ensure that we clean up the script on return. > JSScriptHolder scriptHolder(cx, script); > >+ // Flag this script as a system script >+ // XXXbz we actually want to flag this exact filename, not anything that >+ // starts with this filename... Maybe we need a way to do that? On the >+ // other hand, the fact that this is in our components dir means that if >+ // someone snuck a malicious file into this dir we're screwed anyway... So >+ // maybe flagging as a prefix is fine. See the comment in jsdbgapi.h: * Associate flags with a script filename prefix in rt, so that any subsequent * script compilation will inherit those flags if the script's filename is the * same as prefix, or if prefix is a substring of the script's filename. In other words, there's no `dirname nativePath` computed here. The prefix is the string you pass in, and if it's a leaf filename, not a directory name, then only that filename is flagged. So your XXXbz comment can go away ;-). sr=me with that. /be

> The prefix is the string you pass in, and if it's a leaf filename, not a > directory name, If my prefix is "/home/bzbarsky/good.js" then "/home/bzbarsky/good.js.evil.js" is flagged. So I stand by my XXX comment. ;)

(In reply to comment #5) > > The prefix is the string you pass in, and if it's a leaf filename, not a > > directory name, > > If my prefix is "/home/bzbarsky/good.js" then "/home/bzbarsky/good.js.evil.js" > is flagged. > > So I stand by my XXX comment. ;) I'll see that and raise you a FIXME. Could you file a bug and cite it with a FIXME: # comment? The bug should ask that prefix matching require either '\0' or '/' after the end of the prefix. Thanks, /be

Fixed on trunk.

Comment on attachment 230757 [details] [diff] [review] Proposed patch This patch causes JS components to get XPCNativeWrapper goodness, since they run as chrome. Safety depends on whether JS components are currently doing unsafe stuff with content-objects -- the ones that are might break... I feel that this is what we actually want.

Oh, I filed bug 346139 about filename prefixes.

Fixed on 1.8 branch.

Comment on attachment 230926 [details] [diff] [review] Patch that I checked in approved for 1.8.0 branch, a=dveditz for drivers

Fixed for 1.8.0.7.