canmove, Confirmed users
737
edits
| Line 136: | Line 136: | ||
== Notable Changes Since 1.0b5 == | == Notable Changes Since 1.0b5 == | ||
=== [https://github.com/mozilla/addon-sdk/commit/658fb89ca4d3dc4a8cfb9616ae873e979a7f3955 | === [https://bugzilla.mozilla.org/show_bug.cgi?id=601295 Bug 601295]: Content script access to the DOM is now proxied === | ||
We've changed the way content scripts interact with web pages, in order to improve security. | |||
Previously, content scripts that accessed DOM objects in the page would frequently access the same objects as those being accessed by the page. This gives rise to two problems: | |||
# many changes to the page would be visible to the page, making it obvious to the page that an add-on was modifying it. | |||
# a malicious page might redefine functions and properties of them so they don't do what the add-on expects. For example, if a content script calls <code>document.getElementById()</code> to retrieve a DOM element, then a malicious page could redefine its behavior to return something unexpected. | |||
To deal with these problems, DOM objects like the global window object are now implemented in a way that ensures that content scripts that access those objects will get the native implementations of their properties and methods. | |||
Content scripts that modify those DOM objects will modify a proxy object instead of the real object. | |||
Finally: sometimes add-ons need access to custom, document-defined JavaScript objects. For example, GMail provides a custom JavaScript API which would not be accessible using the proxy. To meet use cases like this, in [https://bugzilla.mozilla.org/show_bug.cgi?id=660780 bug 660780] we've provided access to the unwrapped window via a global <code>unsafeWindow</code> object in content scripts. But note that this is experimental and may change or be removed completely in future releases. | |||
=== [https://github.com/mozilla/addon-sdk/commit/658fb89ca4d3dc4a8cfb9616ae873e979a7f3955 Changes to linker search behavior] === | |||
This changes the way the SDK's linker resolves <code>require()</code> statements, making it more compatible with [http://www.commonjs.org/ CommonJS] and [http://npmjs.org/ NPM]. | This changes the way the SDK's linker resolves <code>require()</code> statements, making it more compatible with [http://www.commonjs.org/ CommonJS] and [http://npmjs.org/ NPM]. | ||