canmove, Confirmed users
737
edits
Jetpack/Release Notes/1.0: Difference between revisions
→Known Issues
No edit summary |
|||
| (10 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== About == | == About == | ||
| Line 77: | Line 76: | ||
See the [https://bugzilla.mozilla.org/buglist.cgi?order=Bug%20Number&bug_status=__open__&product=Add-on%20SDK complete list of known issues and requests for enhancement]. We've listed some of the more important issues separately below. | See the [https://bugzilla.mozilla.org/buglist.cgi?order=Bug%20Number&bug_status=__open__&product=Add-on%20SDK complete list of known issues and requests for enhancement]. We've listed some of the more important issues separately below. | ||
'''[https://bugzilla.mozilla.org/show_bug.cgi?id=636268 Bug 636268]''' | |||
If your add-on has a long name, and the path to your Firefox profile is long enough, then the XPI installation process will try to create an intermediate file with a name longer than the maximum supported length on some Windows systems. If that happens you may get an error like: | |||
<pre> | |||
"<your add-on> could not be installed because Firefox cannot modify the needed file" | |||
</pre> | |||
The main fix for this will be [https://bugzilla.mozilla.org/show_bug.cgi?id=638742 bug 638742], which is to stop unpacking the XPI completely. When that is done, none of the pathnames will matter: they'll all stay safely trapped inside the zipfile. At that point, the name of the XPI file and the length of the profile directory will be the only issues. | |||
Until then, the best advice is to use shorter package names or install Firefox higher up the directory tree so the profile directory's absolute path is shorter. | |||
'''[https://bugzilla.mozilla.org/show_bug.cgi?id=663480 Bug 663480]''' | |||
The SDK automatically includes a dependency on the packages supplied with the SDK such as [https://addons.mozilla.org/en-US/developers/docs/sdk/1.0/packages/addon-kit/addon-kit.html <code>addon-kit</code>] and [https://addons.mozilla.org/en-US/developers/docs/sdk/1.0/packages/api-utils/api-utils.html <code>api-utils</code>]. This means that you can <code>require()</code> modules in the SDK such as [https://addons.mozilla.org/en-US/developers/docs/sdk/1.0/packages/addon-kit/docs/widget.html <code>widget</code>] without having to specify <code>addon-kit</code> as a dependency. | |||
You can also use modules from other packages, such as the packages listed [https://wiki.mozilla.org/Jetpack/Modules here], by including a reference to the package in your [https://addons.mozilla.org/en-US/developers/docs/sdk/1.0/dev-guide/addon-development/package-spec.html <code>package.json</code>] file. | |||
However, if you do add any dependencies to <code>package.json</code>, then the SDK will no longer add <code>addon-kit</code> or <code>api-utils</code> automatically, and you must add them manually if you want to include their modules. | |||
'''[https://bugzilla.mozilla.org/show_bug.cgi?id=663048 Bug 663048]''' | '''[https://bugzilla.mozilla.org/show_bug.cgi?id=663048 Bug 663048]''' | ||
| Line 126: | Line 145: | ||
Selection events for a page are not sent if the page did not fully load (for example, because the user stopped the page loading). | Selection events for a page are not sent if the page did not fully load (for example, because the user stopped the page loading). | ||
== Changes Since 1.0b5 == | == Notable Changes Since 1.0b5 == | ||
=== [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. | |||
=== Cross-site XmlHttpRequests are no longer permitted in content scripts in Firefox 5 === | |||
Firefox 4 allowed content scripts to make cross-site requests using <code>XmlHttpRequest</code>. So, for example, if you injected a content script into http://www.mozilla.org/, the content script would be allowed to send a request to http://www.google.com/ using <code>XmlHttpRequest</code>. | |||
It was always the intention that cross-site requests should '''not''' be possible in a content script, and in Firefox 5 this is no longer possible. | |||
=== [https://github.com/mozilla/addon-sdk/commit/658fb89ca4d3dc4a8cfb9616ae873e979a7f3955 | === [https://github.com/mozilla/addon-sdk/commit/658fb89ca4d3dc4a8cfb9616ae873e979a7f3955 Changes to linker search behavior] === | ||
This | 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]. | ||
It's documented in the [https://github.com/mozilla/addon-sdk/commit/658fb89ca4d3dc4a8cfb9616ae873e979a7f3955 GitHub commit] and in the [https://addons.mozilla.org/en-US/developers/docs/sdk/1.0/dev-guide/addon-development/module-search.html Module Search] guide in the SDK. | It's documented in the [https://github.com/mozilla/addon-sdk/commit/658fb89ca4d3dc4a8cfb9616ae873e979a7f3955 GitHub commit] and in the [https://addons.mozilla.org/en-US/developers/docs/sdk/1.0/dev-guide/addon-development/module-search.html Module Search] guide in the SDK. | ||
=== [https://bugzilla.mozilla.org/show_bug.cgi?id=653256 Bug 653256]: Make smaller XPIs by only including modules that are actually used === | |||
Previously, if you used any modules in a package, then your XPI would include all modules in the package. With this change only modules you actually use get included. | |||
Note that this is behavior is not currently the default: to enable it you need to pass the experimental <code>--strip-xpi</code> option to <code>cfx</code>. | |||
=== [https://bugzilla.mozilla.org/show_bug.cgi?id=615921 <code>timers</code>] and [https://bugzilla.mozilla.org/show_bug.cgi?id=615244 <code>self</code>] modules are moved from api-utils to addon-kit === | |||
This should not affect anyone currently using either module, but reflects the fact that both of these modules are heavily used by people writing add-ons. | |||
== Feedback and Bug Reports == | == Feedback and Bug Reports == | ||
We'd love to hear any feedback you have regarding this release! You can post it to the [http://groups.google.com/group/mozilla-labs-jetpack discussion group] or [https://bugzilla.mozilla.org/enter_bug.cgi?product=Add-on%20SDK&version=1.0 report a bug]. | We'd love to hear any feedback you have regarding this release! You can post it to the [http://groups.google.com/group/mozilla-labs-jetpack discussion group] or [https://bugzilla.mozilla.org/enter_bug.cgi?product=Add-on%20SDK&version=1.0 report a bug]. | ||