canmove, Confirmed users
737
edits
Jetpack/Release Notes/1.0: Difference between revisions
→Known Issues
No edit summary |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 76: | 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]''' | '''[https://bugzilla.mozilla.org/show_bug.cgi?id=663480 Bug 663480]''' | ||
| Line 149: | Line 161: | ||
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. | 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. | |||