Category: Extensions

I’ve mentioned plugin monitoring, a student project from Seneca College, back when the developers sucessfully got their project “marks”. I am quite pleased to see the project actually land in Firefox 3 (Mozilla 1.9) last week (bug 412770).

Fima (gluon) worked through the review process and landed the monitoring portion of the project. Now, extension developers can use an nsIObserver notification (“experimental-notify-plugin-call”) to monitor the processing time used by a plugin. Fima created an MDC article to cover the details. His blog has many posts on the subject.

He also has a Firefox extension you can use to monitor long running plugin code.

It’s a cinderella story complete with fairy godmothers.

Over the weekend, code landed to restrict the ability of web content to access “chrome://” resources (see bug 292789). This shouldn’t affect many extensions since the restrictions are focused on web content, not chrome content. However, if your extension injects content into the web content, you could be affected. An example can be found in bug 428848. Venkman can’t load venkman-source.css, a stylesheet that is injected into unprivileged, web content.

The solution to this problem is a new chrome manifest flag – contentaccessible. Using contentaccessible, an extension author can say “Yes, I’d like my extension’s chrome package to be accessible to web content.”

Note, in bug 292789, that chrome://global and chrome://browser packages are exposed to content by default. This is required to keep remote XUL (XUL loaded into web content) working.

See Wladimir Palant’s post on this topic too.

And making Firefox 3 ignore extension compatibility checking is wrong!

Firefox 3 is really close final release. Many of you have started using Firefox 3 for your daily browsing, as have I. You might discover that some of the extension you love have not been updated to Firefox 3 or maybe just not updated to the latest beta. So you search the web and find posts and tools for magically making old extension “work” in Firefox 3.

The Lifehacker post says “Make Your Extensions Work with the Firefox 3 Beta.” Nightly Test Tools adds a button to “Make all compatible.” This is snake oil my friend and you could be faced with nasty consequences.

These methods DO NOT make your old extension updated to work in Firefox 3. They turn off Firefox’s builtin extension version checking system. These methods should only be used for testing, not everyday browsing.

More than a few of the top-crashing bugs (reported when Firefox crashes) are due to users running old, incompatible add-ons. Please, turn on the compatibility checking. If you can’t wait for your favorite add-on to be updated, maybe it’s time to look for a new add-on. Firefox 3 is the leanest, fastest, most feature packed version we have ever released. Don’t foul it up with old crappy add-ons.

Firefox 3RC1 is just around the corner. Surprisingly, more than a few of the current Top 100 add-ons on AMO are not updated to work in Firefox 3. I say “current” because when Firefox 3 ships, those old add-ons will no longer be in the Top 100. Alex Polvi has a chart (updated daily) showing the status of Top 95% of AMO add-ons (by usage). You can see that many of the Top 100 have been updated to at least Firefox 3.0b3 or greater.

Many of the non-updated add-ons are themes. Themes are hard to create in the first place and with significant changes to the Firefox 3 UI, updating themes from Firefox 2 could be a daunting task. Worse yet, getting a them to somehow support Firefox 2 and 3 in the same bundle is not trivial.

AMO was recently updated and is constantly improving to make things easier for add-on developers. Being able to host separate bundles for different versions of Firefox would be a big help.

The remaining non-updated add-ons will likely fade away after Firefox 3 is released unless the authors or someone else (with the author’s permission) decide to do the work needed to update to Firefox 3. Keep in mind, add-ons in the Top 100 have hundreds of thousands of daily users. Add-ons in the Top 10 have millions of daily users.

Just as in nature, “survival of the fittest” applies to add-ons too. Let’s hope we can avoid one of those mass extinctions.

Note: To those add-on developers who went through the effort to update your add-ons to Firefox 3 alpha or beta (1 or 2), please take the small amount of time needed to push your add-on to Firefox 3.0pre. Don’t let your users miss out on your add-on when it’s soooo close to completely updated.

As always, #extdev on Mozilla IRC or the extensions newsgroup for help.

One of the new XMLHttpRequest features in Firefox was cross-site requests. It was based on an W3C specification and would have allowed web content to make cross-site XMLHttpRequests. I say “was” and “would” because that feature was removed in Firefox 3.0b5 due to security concerns and some specification changes too close to the Firefox 3 release.

Extension developers have always been able to use cross-site XMLHttpRequests and this change will not affect your ability to keep making cross-site requests. It only affects web content.

Rest assured, cross-site XHR for web content will be back, just not in Firefox 3.

I love reporting “unbreaking news” and I have some report. I posted about a security change (bug 418356) to mozIJSSubScriptLoader that broke loading scripts from any non-chrome URI. An alternate fix has landed that allows file: and resource: URIs to be loaded by the subscript loader again.

Therefore, this will continue to work:

var obj = {};
var loader = Components.classes["@mozilla.org/moz/jssubscript-loader;1"]
                       .getService(Components.interfaces.mozIJSSubScriptLoader);
loader.loadSubScript("file:///blah.js", obj);

Unfortunately, data: URIs are harder to secure and will not work with the subscript loader. Fortunately, there are workarounds for data: URIs – you can save the script to a file and use file: or you can use evalInSandbox to evaluate the script.

Thanks to Boris Zbarsky and Johnny Stenbeck for the more robust fix.

XMLHttpRequests (XHR) are used for lots of things these days. When running a background XHR, however, you might experience some common issues like authentication or bad SSL certificate dialogs popping up. Another problem was starting an XHR, then closing the window – the XHR is closed. To help get around these inconveniences, Manish Singh (of Flock) adding support for a background mode (bug 383430). The details:

• Do not attach to a window’s load group, so requests aren’t cancelled if the window closes (often the window isn’t really associated with the request anyway)
• Do not get an nsIAuthPrompt by default, since we don’t want authentication dialogs to pop up randomly.
• Provide an nsIBadCertListener implementation, again to prevent bad certificate dialogs to pop up randomly.

var req = new XMLHttpRequest();
req.mozBackgroundRequest = true;
req.open("GET", someURI);
req.send(null);

The magic is handled by mozBackgroundRequest and it’s only available to chrome, not for web content.

Global extensions are extensions that are not installed into a profile. Therefore, the extensions is always available, even in a new profile. Yes, I am talking about extensions, not plugins. Plugins can also be global, there are a few ways to achieve this on the various platforms (Windows, Mac and Linux).

However, only Windows had the capability to install global extensions, using the Windows registry. Thanks to bug 311008 and bug 412449, global extensions are now possible on Linux and Mac too. The magic paths:

Linux:

/usr/lib/mozilla/extensions/ (or /usr/lib64/mozilla/extensions/)
/usr/share/mozilla/extensions/
~/.mozilla/extensions/

OSX:

/Library/Application Support/Mozilla/Extensions/
~/Library/Application Support/Mozilla/Extensions/

Note that it is possible to limit the extensions to a specific user as well. The new MDC documentation goes into more detail. Hopefully, this makes deploying 3rd party extensions a bit easier.