In both the Add-on SDK and WebExtensions, persistent scripts can’t directly access the content of web pages. Instead, extensions can attach content scripts to web pages. These scripts:
- do get direct access to web content
- don’t have access to privileged APIs
- can communicate with the persistent scripts using a messaging API.
In both technologies, there are two ways to attach scripts: you can automatically attach a set of scripts to pages whose URL matches a given pattern, or you can programmatically attach a script to the page hosted by a given tab. The way to do this is different in each technology, though:
The match patterns used for URLs are different:
In both technologies you can pass options to control when the script runs and whether it will be attached to subframes. WebExtensions don’t include an equivalent of
contentScriptOptions, though, so to pass configuration options to a content script in an extension, you would either have to send them in a message or store them in
In both technologies, content scripts can communicate with persistent scripts using an asynchronous messaging API:
In both cases, content scripts can communicate with scripts loaded by the page using
In both technologies, have access to the page they’re injected into, but get “a clean view of the DOM”, meaning that they don’t get to see modifications made to the DOM by scripts loaded by the page.
In the SDK, content scripts can share objects with page scripts, using techniques like
createObjectIn. With WebExtensions, the
unsafeWindow is available via
wrappedJSObject instead. All the export helper functions are available, too.