Greasemonkey 0.9.3 Release

Bug fixes:

• Error message logged ("Redeclaration of const document")/high CPU usage when closing the sidebar. (#1226, #1298)
• Navigating to a .user.js inside a frame works like anywhere else. (#1248)
• The list of user scripts in the Add-ons Manager would sometimes forget its sort order. (#1307)
• Compatibility enhancement with AutoPager (broken in 0.9.2). (#1344)
• Passing a non-function to GM_registerMenuCommand()'s commandFunc broke the entire menu, and items showed up in the wrong order (both broken in 0.9.2). (#1346, #1347)
  

Enhancements:

• Passing the Referer header works, for GM_xmlhttpRequest(). (#1240)
• Accessibility: The sort buttons in the Add-ons Manager work with keyboard input (space/enter). (#1345)

The entire list of bugs handled in this release is also available via the 0.9.3 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, and it's available on the all versions page. If you are using it and notice problems, it's best to either let us know at greasemonkey-dev or log an issue (and be clear that it's with this version).

Breaking change: Inject into about:blank?

Back in version 0.8.2 we patched a security/privacy hole by preventing injection into file: and about: scheme URLs. This was August 2009, and at the time we specifically allowed about:blank (while blocking the rest of about:). A carefully crafted web search, [site:userscripts.org/scripts/review/ "about:blank" -"src about:blank"] reveals (among plenty false positives just making frames/windows that start blank) that real scripts are using this feature. Examples include:

• Super Imgur Script

Then there's scripts specifically avoiding about:blank:

• Cookie Zapper On Tab Close
• Content Concealer
• Go to bottom and go to top floating links
• Taggable
  

Yes, I ended up finding only one real script using this feature. In much the way that I imagined it way back when. But I found four specifically trying to avoid it.

We now know of one real, serious bug with this approach. It happens to have an easy workaround, but really brings to light the issue: The about:blank page has a sort of special meaning. In this bug we know about, the browser is using a navigation to about:blank as a sort of clean-up, meaning "this content is gone", much like assigning null as a cleanup activity in some programming languages.

Therefore our current plan is to not inject scripts into about:blank unless the @include rule specifically mentions it. So if you say @include about:blank#mycustomvalue then everything will work as it does. But if you say @include * (or rely on that default) then you will not run on about:blank. Current plans would include this change in the upcoming version 0.9.3.

(As always, please find us on greasemonkey-dev to discuss the development of Greasemonkey itself.)

Greasemonkey 0.9.2 Release

This release primarily fixes some of the problems discovered since 0.9.0.

Bug Fixes:

• Failure on OSX when Growl is installed, but not running. (#1264)
• Incorrect display of Greasemonkey icon in Add-ons window (Firefox 3.6, OS X). (#1284, #1291)
• Provide a sort bar, to control display order of the scripts in the Add-ons manager, for Firefox 4. (#1293)
• Remove "accelerator" keys from GM_registerMenuCommand(). (#1312, previously)
• Work around incompatibility with Personas Plus extension. (#1253)
  

Enhancements:

• Provide a toolbar button, and remove the status bar icon for Firefox 4. (#1227)
• When re-installing a script (e.g. for an update), keep it in the same execution order. (#1267)
• Keep the add-ons manager view up to date when changing (installing/enabling/disabling/etc) user scripts. (#1305)

It should be available soon, pending normal delays for review.

Greasemonkey Usage, by Firefox Version, April 2011

I'd like to take the opportunity to review the current usage profile of Greasemonkey, as it relates to Firefox version. There's a couple points to be made, in regards to the work we've been doing recently on the 0.9 version branch of Greasemonkey. This data all comes from the addons.mozilla.org statistics for Greasemonkey.


First, we can quickly note that Firefox 1.x and 2.x combined total only one half of one percent of current usage. This is why we decided to up the minimum compatible version to 3.0. It wasn't worth the effort to try to keep things working in earlier browsers.

Also, now that Firefox 4.0 is out for a while, we can see why we went to 3.0 minimum, and not 4.0. So far only about one fifth of our users have upgraded. For everyone else, we think the recent enhancements we've been making are worth having, so we've taken special effort to make sure that we stay working in Firefox 3, and don't rely on features only available in Firefox 4. Over time, perhaps that will change. The slope is quite steep right now, but if history is any guide, there will be a substantial minority of users that stick with Firefox 3 for some time.

For reference, here's the exact data.

GM_registerMenuCommand() losing "accelerator key" feature

Script authors, take note: I'm planning on moving forward with a change to remove a small part of the functionality of GM_registerMenuCommand(). This post is to explain what part, and the justification for doing so.

With the release of Firefox 4, Mozilla has made some grand changes to the look and feel of the browser. They've moved tabs to the top, emphasized the Firefox Button over the menu bar, and removed the status bar (providing the addons bar as a temporary shim for extension compatibility). This led us to re-build parts of Greasemonkey to focus on providing a toolbar, and de-emphasize the old "monkey menu" in the status bar.

It turns out that the menu code, now controlling the Tools > Greasemonkey menu, the old status bar monkey menu (in Firefox 3.x), and the new toolbar button's menu, also controls the commands for GM_registerMenuCommand() (to put them in the menu, of course!), which also controls the "accelerator keys" for those commands.

These accelerator keys have, more or less, never worked. I've written a test script (see the source, or install it) to demonstrate this. Once installed, navigate to the page about:blank#GM_rmc (you might need to hit reload, depending on how you open this) to run the script. Pick any combination of modifiers, and a letter for the accelerator key. Then try to use that accelerator key.

I'm testing on Firefox 3.6 and Greasemonkey 0.8 -- the last versions before some of these big changes started, where everything should still be as reliable as it ever was.

I ran this test: Close Firefox, launch it to the test page with only one tab open. Register a single menu command. Open the monkey menu, click on the menu item and see the alert. Press the accelerator key. No alert. I repeated this whole process for: Shift+Ctrl+Q, Alt+Shift+X, Control+M. None of it works. I saw it working with at least one earlier attempt, but even then it was fragile: normal actions like loading pages or closing tabs caused otherwise working keys to fail.

I tried a super-simple script and it too doesn't work. Installing it and pressing Ctrl+Shift+C gives me no results, but selecting the menu item does.

I've asked on our mailing list, I've asked at userscripts.org, and I've held discussions with developers. I can't find anyone that will regret losing accelerator key support in GM_registerMenuCommand(), and all my attempts to make it work well have so far failed.

So it is going to be removed, in Greasemonkey 0.9.2. Unless I hear from someone that can show me that I've been a fool, it does work, and I'm using it wrong. Please use the mailing list to get in touch with us if so!