Firefox has several layers in which Javascript functions can be run:
- "chrome": the browser itself and any extensions that are installed. These can essentially do anything.
- "web": HTML/XHTML/XML/etc pages loaded in a browser window. These have limited privileges - they can't read information from different domains, access local files, or call any of the "chrome" functions.
- "sandbox": By creating a sandbox, then loading a document into an XPCNativeWrapper within the sandbox, chrome can make an area in which certain Javascript (that which is loaded from external files or within the document) has "web" privileges and other Javascript (loaded from chrome files, or eval-ed from chrome in the sandbox - see below) has "chrome" privileges. This is how Greasemonkey and Zotero provide functions like cross-domain XMLHttpRequest and interactions with chrome functions to their userscripts/translators.
Firefox extensions that want to use a sandbox to run user scripts will create a sandbox area, add a document to the sandbox, load Javascript from local files (or generate it), then use evalInSandbox to run that code on the document in the sandbox.
The code run using evalInSandbox will be able to call chrome functions, so must be protected from Javascript running in the original web page: for this reason many functions in the sandbox are unavailable (for example, it's not possible to use watch() to see when an object changes). There are also security hazards to bear in mind when using the sandbox - for example you shouldn't trust the properties of any object in the sandbox to remain unaltered.
A lot of the practical effects of using XPCNativeWrappers are explained in Mark Pilgrim's Avoid Common Pitfalls in Greasemonkey, written a couple of years ago when Greasemonkey was altered to make use of XPCNativeWrapper in order to avoid security holes.
Opera, Safari and IE all have either built-in or third-party support for user scripts, but no details on whether there's any kind of secure sandbox in which they're executed.