Wednesday, December 12, 2012

The First Anonymous Statistics Summary

For context, see the previous post Anonymous Statistic Gathering.  As of release 1.5 almost four weeks ago we added opt-in statistics gathering.  The goal is to let us know the sorts of things that real users are doing, to help inform future development decisions.  This is the first post where I start to look at the data that's been gathered, in aggregate.

Let me stress that point for a moment: in aggregate.  It is my intent to never publish or reveal specific users' data in any way.  When I do it will be in aggregate, like the rest of the post.  I actually never plan on even reading the specific rows carefully, unless there is a very specific issue to address.  That's part of the reason that I'll have no links or sources for any of the data below, like I would do for other things.  You've just got to trust me that it's accurate, I'm not sharing specifics on purpose.

That said, the first interesting piece of data is the opt-in rate.  According to Mozilla's statistics, Greasemonkey 1.5 has 2,092,151 users (basically everyone is using 1.5 besides some users still on 0.9, presumably also on older Firefox versions).  There are 23,790 distinct users sending data, which is just 1.14%.  But still hopefully enough

The distribution of submissions is interesting.
Submissions peak on Wednesdays, as version 1.5 was first made available on November 19th (the 20th, the next full day, being a Wednesday) with a weekly reporting period.

Among the users reporting data, by far the most common number of scripts installed is one; nearly half of all reporting users have only one script installed.  The next most common configuration is zero scripts installed!  While four users are reporting one hundred scripts or more installed, 95% of all users have ten or fewer.
Zero scripts installed by over twenty percent of users makes me worry that there might be a recording/reporting bug.  So this is worth revisiting.  Or if it's correct, it might warrant some sort of messaging to such users to coach them into getting use out of Greasemonkey.

The next interesting thing we can do is look at metadata imperative usage, where we are counting scripts by the number of times they are installed by real users, not once each for all that exist like we've done before.
This looks pretty familiar, if you followed the link above.  The top eight come in the same order, with similar percentages, following a similar power law curve.  Grant is used in 9.09% of scripts.

Finally one more number worth watching.  Today, just a bit under two thirds of installed scripts depend on implicit @grant detection.  Almost all of the remaining third need no grants at all, but it will be some time before we can remove that backwards-compatibility feature.  On the other hand, I'm currently detecting exactly zero scripts with explicit grants; I know that's wrong because I have some installed, and because usage of grant was at 9% in the graph above.  I'll need figure whether I'm reading the data wrong, or if it's being reported wrong.

Monday, November 19, 2012

Greasemonkey 1.5 Release

The entire list of bugs handled in this release is also available via the 1.5 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

Enhancements:
  • Improve the clarity of the error message when installing a script with a missing sub-resource. (#1666)
  • Create opt-in only statistics gathering.  See the post about this. (#1651)
  • When displaying an update that has been found but not installed due to user settings, show the version that will be installed by the update, not the version already installed.  (#1497)
Bug fixes:
  • Fix a failure to download updates when one is found. (#1669)
  • Fix the enable/disable pattern on the User Script Commands sub menu. (#1665)
  • Do not break the script when adding a bad (i.e. 404) URL as a new @require. (#1661)
  • Avoid loops when the resource at downloadURL and updateURL disagree about the newest available version. (#1659)
  • Fix when relative URLs are provided for downloadURL or updateURL. (#1658)

Wednesday, November 07, 2012

Anonymous Statistic Gathering

In release 1.5 Greasemonkey will add anonymous statistic gathering.  This feature will be opt in only.  Users will be asked to opt in, but no data will be transmitted unless they do.

For users that do opt in, a randomly generated persistent ID will identify this Greasemonkey installation as being distinct from others, and then certain data will regularly be gathered and transmitted to a central server for analysis along with this ID.  The goal is to improve Greasemonkey by better understanding how real users go about using it.

We intend to collect data like:
  • How many user scripts are installed
  • Which internet sites those scripts were installed from
  • What sort of API features those scripts use
  • What sort of Greasemonkey features users actually exercise
  • The exact browser and operating system that Greasemonkey is running on
We have written a privacy policy to explain exactly how this data will be used.  The short version, however, is that we never intend to share this data in anything but an aggregated form.  For an example of the sort of aggregated data we mean, see the Greasemonkey API Usage post.

To control this feature, a new check box is being added to the Greasemonkey Options dialog.


If you opt yourself in and later want to opt back out, or vice versa, you can use this check box.  The Greasemonkey Options dialog can be found through the monkey menu, in Tools > Greasemonkey > Greasemonkey Options, or the Preferences button for Greasemonkey in the Add-Ons manager.

Sunday, October 07, 2012

Greasemonkey 1.4 Release

The entire list of bugs handled in this release is also available via the 1.4 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

Enhancements:
  • The User Script update code has been revamped and simplified to be completely integrated with the standard Firefox Add-on update system.  Opting in and out of update checking and installing now uses the base Firefox settings.  If you are opted out of automatically installing updates, there should be an "Updates" tab in the Add-ons Manager where you can review and optionally install them.
Bug fixes:
  • Fix updates (see enhancement above).  Especially: a bug that installed updates far too often, when they should not have been.  (#1646, #1647)
  • Fix an obscure case which could cause Firefox to crash in Ubuntu Linux. (#1632)

Thursday, September 27, 2012

Greasemonkey 1.3 Release

The entire list of bugs handled in this release is also available via the 1.3 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

Enhancements:
  • The "Show Script Source" button in the install dialog is enabled as soon as the script source is downloaded. (#1640)
  • Use new style non-modal popup notifications where old toast style notifications were used. (#1563)
Bug fixes:
  • A false "update" was installed on every page load. (Cause: #1636 Fix: #1643)

Greasemonkey 1.2 Release

Update: I accidentally left issue #1643 in this release, and noticed it just a bit after making it public.  So this release has been pulled.



The entire list of bugs handled in this release is also available via the 1.2 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

Enhancements:
  • Enhance compatibility with Add-on Update Checker. (#1621)
  • Add resources property to GM_info. (#1610)
Bug fixes:
  • Fix __exposedProps__ issues with GM_xmlhttpRequest and GM_listValues. (#1637, #1629
  • Don't auto-install script updates when that preference is turned off. (#1636)
  • Run scripts at a http://user:pass@domain/ style URL. (#1631)
  • Fix GM_registerMenuCommand (broken in 1.1). (#1627)

Friday, September 14, 2012

The Design of Greasemonkey 1.0


This is a long, deep, technical post.  The goal is to share Greasemonkey's history, to help explain how the decisions made in Greasemonkey 1.0 were reached.  Hopefully if you have any interest in user scripting, and especially if you are a script author, you'll find it enlightening.

Greasemonkey is at least seven and a half years old (version 0.2.5 was released on March 28, 2005; version 0.2 seems to date from January 14th, version 0.1 from way back on December 6th, 2004).  Greasemonkey in particular and user scripting in general, not to mention the browser platforms they rely upon, have come a long way in the past eight years or so.

If you examine the version history of Greasemonkey, you'll see that core APIs like GM_xmlhttpRequest and GM_getValue/GM_setValue were added very early on.  They've helped define a lot of what user scripting is: a quick and simple way to fix/enhance existing web sites with (generally) short and simple javascript programs.  These APIs were simple by design, yet more powerful than what standard javascript (in a web page) can do.

One of the early great scripts was Book Burro, which allowed users to compare book prices at Amazon, Barnes & Noble, and others, right on the existing web page.  This was possible only because GM_xmlhttpRequest allowed the user script to break the same origin policy that would be applied to a normal XMLHTTPRequest call made by a web page.  The ability to store persistent values and use them at next run also enabled things like adding a search history to GMail.

These features aren't provided to normal scripts on web pages, because they can be dangerous.  They were provided to scripts, because the user has much more control over which scripts they choose to install.  Links clicked online can point to any web site, with any potentially malicious goal, so they're much harder to control ahead of time.  It was in July of 2005 that Mark Pilgrim pointed out the giant unfortunate security hole in the way that Greasemonkey gave user scripts access to these more powerful APIs, which made it possible for malicious pages to access and use them.

This is when Greasemonkey's security sandbox came into being.  Greasemonkey version 0.3 was public at the time that this security problem became evident.  Version 0.4 was in development, but was scrapped to build 0.5 which contained the security fix, later in the same month.  It was right at this time that Mozilla was implementing XPCNativeWrappers into Firefox.  This formed the core of the execution model that Greasemonkey has used ever since, until the release of Greasemonkey 1.0, a span of over seven years.  An entire article, at least this long, could be written just on the repercussions of this change.  In short, as the linked page says, "XPCNativeWrapper is a way to wrap up an object so that it's safe to access from privileged code."  In this case the privileged code is the user script (with the APIs that Greasemonkey grants it), and the wrapper makes it "safe to access" the untrusted web page with potentially unsafe javascript code.

The Greasemonkey Hacks O'Reilly book which was in progress at the time needed to be completely rewritten, as many of the scripts it contained would no longer function properly.  As part of this rewrite, the Avoid Common Pitfalls section was added, based on the author's insight from reading and re-writing dozens of scripts to deal with the issues this security focused change caused.  (And the pitfalls commonly tripped up script authors.)

This was the only intentional backwards-incompatible change (anything else was a bug, and fixed) in Greasemonkey's eight year history, until version 1.0.  I bring this up primarily to stress the point that we really do care about maintaining compatibility.  We broke it again in version 1.0, and not lightly, but rather because after years of experience (and changes around us), we decided it was the right thing to do.

But why?  Partially because we think it's a very small break.  Few scripts should be affected.  But also, go back and read that common pitfalls article.  It's long and complicated.  It relates to a number of things that may be completely natural, for experienced javascript programmers, and especially for new ones just trying to follow tutorials.  Time and time again, script authors would come to us with problems, saying that the script works fine in a web page (or the Firebug console, or similar), but fails in Greasemonkey.  And fails mysteriously.  Usually no error is given, sometimes something cryptic, but the answer is never obvious unless you know it already.  This makes developing scripts hard, which is not awesome.

On top of the broken features, the security restrictions mean that interacting with javascript on the page is harder.  The security restrictions intentionally isolate the script in the page (content scope) from the user script (script scope).  But when the script tries to alter the content scope, it can't.  There are plenty examples of authors trying this, and failing.  Then there's the location hack and reading content globals workarounds.  And the setTimeout access violation workaround for when content callbacks trigger script functions.  And the pitfalls article.  But you need to know both that these problems, and their workarounds, exist in order to use them!

Let's not forget unsafeWindow.  This beast was created back when the legacy security sandbox was added.  Some times, you just need to poke at the content scope.  With the legacy sandbox, sometimes unsafeWindow is the only way to do this.  But that name wasn't picked lightly.  The unsafeWindow object is unsafe!  Back in 2008, I figured out a way around the security sandbox, for any script that used unsafeWindow for any purpose.  That particular hole has been patched, and we're not aware of any others.  But that doesn't mean they don't exist.

Unfortunately, usage of unsafeWindow is extremely widespread.  My API usage survey showed it to be the most commonly used Greasemonkey feature, where using none at all was the only more common case.  Nearly one of five scripts use it.  And there's always the chance that it could cause real security or privacy issues, through some avenue which we simply aren't aware of yet.  If so any site that a script accesses via unsafeWindow could gain all of the Greasemonkey APIs.  Which means GM_xmlhttpRequest, and the ability to interact with any site you're logged into, whether it's Facebook or your bank.

The whole problem boils down to the security restrictions that keep the content scope and script scope both separated and different from each other.  The big idea in Greasemonkey 1.0 was to change this model.  I discussed something like this in 2009 and Johan brought it up again in 2011 with some distinct details.  In short, web browsers and javascript have come a long way since 2004.  There are features like DOM Storage and postMessage, and all the things popularly labeled as "HTML5".  Scripts can use these features, rather than the Greasemonkey specific ones.  Even more importantly, though, a majority of scripts don't use any special Greasemonkey APIs.  Yet they bear all the compatibility burdens that the security sandbox imparts while protecting these unused APIs.

So the goal of Greasemonkey 1.0 was to make it possible for the most common class of scripts, with no need for special APIs, to work just like a content script, with all the new features that the browser supports, with all the standard methods javascript programmers are used to (including jQuery), without breaking anything.  And none of the mysterious failure modes.

The way we chose to do this is to make the APIs an opt-in feature, rather than on by default for everybody like they always were before.  This is what the @grant metadata does.  It says "I really need it, so I want this special API for my script" and, as a result, I'm willing to deal with the limitations of the security sandbox it will be put into.

But for the past eight years, this hasn't existed, so nobody has used it.  What about all the scripts written in that time?  In Greasemonkey 1.0, simple content sniffing is performed on the script.  If it looks like it calls an API function, then Greasemonkey acts like the appropriate @grant line was given, even if it wasn't.  If you want the new execution mode where everything (besides the privileged APIs) works for sure, you simply specify @grant none in your metadata.

This mode also puts you much closer to the content scope.  From the script scope, you can read any content scope variable simply by using its name.  No reading content globals workaround.  And you can even write to the content scope, simply by addressing it as "window.thing = value".  No location hack necessary.  (In more javascript-y terms, window is the content global scope; in the script this is the script global scope.  And this has window as its prototype.)

Examining every existing script hosted at userscripts.org shows that not a single one does this (assigning a value to a property of window) today (so they won't get different broken semantics).  Unfortunately, jQuery does, so it needs to be fixed.  But the fix is the standard and documented jQuery feature for such a case.  On the other hand, if the page you run on already includes jQuery, then you can just use it!  You have direct read access to the global content scope!

Eventually, @grant none will become the default.  At that point, we will stop sniffing and faking grants that were not specified.  And at that point you will be required to specify the grant for any API that you do still actually want to use.  Only time will tell when we're comfortable enough making that change.

Finally, don't forget about the grant-none-shim.user.js, which provides an emulation layer for most of the Greasemonkey APIs on top of standard browser features.  If you (for example) use getValue/setValue or xmlhttpRequest, but only on a single origin, you can switch to this and get the thin sandbox goodness of a grant none style script, and everything will generally work as it always did, at little to no cost.  Just note that existing stored values will no longer be readable.

Thursday, September 06, 2012

Greasemonkey 1.1 Release

The entire list of bugs handled in this release is also available via the 1.1 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

Enhancements:

Bug fixes:
  • Fix a Firefox crash caused by a bad greasemonkey-script: URL (i.e. passing the empty string, or a nonexistent resource name to GM_getResourceUrl().) (#1623)
  • Re-fixed the setTimeout + alert issue; it popped up again in the grant none case. (Note: Firefox 16 fixes this for real. This just applies the same old workaround.) (#1620)
  • Fixed the character encoding of the es-CL translation. (#1616)
  • Fixed the display of the "Enabled" check mark in the monkey menu. (#1611)
  • Fixed the "Show Script Source" button for some scripts.  (#1609)
  • Killed the final remaining zombie compartment (i.e. memory leak). (#1608)

Thursday, August 30, 2012

Greasemonkey API Usage -- August 2012

Back in November 2009, I analyzed the API usage, and a few other aspects, of all the scripts on userscripts.org, then 36,141 scripts.  I was directly discussing some of the topics that were already bubbling around the back of our minds, for how to carry Greasemonkey into the future with us.  The short version is: web browsers and web apps are getting so much poweful, why do we need these one-off Greasemonkey APIs with cross-browser problems?

Now that Greasemonkey 1.0 is out, we've made big steps made in that direction, and I've repeated the analysis.  I downloaded (with permission from the site owner) every single active script on userscripts.org, now 82,084 scripts.

First up, which API calls are made, and how common are they?
API Usage by Number of Scripts

Not much has changed.  By far most common is that a script doesn't call any special APIs (57.94%).  Then, GM_getValue/GM_setValue are still right up there.

The biggest change is that unsafeWindow usage has jumped from 6th to 2nd place (12.44% to 17.65% of scripts; 1,527 scripst also mention wrappedJSObject, not on the chart).  Authors want to interact with the page in ways that the security sandbox (which protects these APIs) prevent, so they explicitly jump out of the sandbox, bringing vulnerabilities with them.  Of the 14,484 scripts that reference unsafeWindow, 6,494 of them use no other Greasemonkey APIs, and thus are served well by moving towards a model where there is no sandboxing (nor APIs, unless you ask for it/them).  Another 838 scripts only use GM_log and/or GM_addStyle, which can easily be replaced with console.log() or the compatibility shim layer.  It gets hard to analyze other calls in more detail, but I see a lot of get/set value calls, which (assuming you run on only one domain) can also be well served by DOM Storage.

Moreover, those 47,557 scripts that don't use any of the special APIs are still saddled with the sandbox and its pitfalls, known and unknown before Greasemonkey 1.0.  Plenty of newer browser features don't work in the security sandbox because its entire point is to separate the content scope (where these features work) from the script scope (with its smaller set of privileged features).  A huge part of the design changes in Greasemonkey 1.0 is to make the default behavior, like these majority of scripts need/want, to run as close to possible as a regular script in a regular web page, without surprises like missing values and broken features.

So do scripts that use get/set value or xmlhttpRequest really need the cross-domain behavior they provide?
API Usage Cross-domain Analysis
(Note: the left-most set of bars is "@include *" and the rightmost is ">5" -- the labels are missing from the graph and I'm not sure why.)
Mostly: no, and this hasn't changed much since 2009.  The vast majority of scripts using get/set value (71.86%) only ever execute on a single domain, and thus can use DOM Storage with no ill effects.

The XHR usage to two domains is lower mostly because I fixed my analysis a bit (i.e. not counting an @include of *.example.com and an XHR to www.example.com as two domains, and not counting XHRs to userscripts.org, assumed to be update checker scripts, which is now provided by Greasemonkey).  However, a combined 44.25% of scripts that call XHR (and with a string literal that I could pull a domain name out of, not a variable set somewhere else) either call to/run on two or all domains, and thus really use the cross-domain power of GM_xmlhttpRequest.

Finally a bit more detail about Metadata imperatives.  This graph is for all imperatives used in at least 1% of scripts, regardless of what they are.
Greasemonkey Metadata Imperative Usage
Most of what has changed since 2009 is the analysis, including more values.  Note that almost every script (99.37%) specifies @name, and we see a power law trail off in usage.  The commonly used, but unsupported in Greasemonkey, ones are @author, @homepage, @license/@copyright, @date, and @history.

Check the raw data to see hundreds more @things, generally all unsupported values.  And there I pasted only those used at least ten times, there are yet more hundreds used fewer times.

To those that are interested: the script that I used to generate these numbers is available for inspection, in case it perhaps contains a serious bug. The raw data that I generated with it, and the charts above, are also available to check.

Tuesday, August 28, 2012

Greasemonkey 1.0 + jQuery: Broken, with Workaround

One of the big changes behind Greasemonkey 1.0 was moving towards the goal of not forcing the security sandbox (and all its pitfalls) upon script authors.  This is the entire reason for @grant, and specifically the @grant none setting.  In the @grant none case, the script does not get the traditional security sandbox (with XPCNativeWrappers), but rather a very thin sandbox that exclusively acts as a private scope, to hold variables for the script that don't interact with the page.

The idea was, if you want to set something in the page, you just do window.foo = 'bar', and if you don't it's just a normal var foo = 'bar'.  But there's a problem.

If you @require jQuery, it implicitly does a window.$ = window.jQuery = ...,  which exports the copy of jQuery that your script is loading into the page.  If they're different versions, there is a very real possibility of completely breaking the page.

This is Greasemonkey issue 1614, which is open and being tracked for a fix.  In the meantime, you can insert a one line fix into your script, at the top level (not inside any functions):

this.$ = this.jQuery = jQuery.noConflict(true);

This line just calls the standard jQuery noConflict() method, so that this loaded version of jQuery doesn't conflict with anything already in the page.  It's already there, it's exactly what it's for!  And saves a local (in the script) reference to the version of jQuery that you want to use.

This should let your script keep working, and also keep the page from breaking.  It's only lightly tested so far; let us know in the comments if it helps you.

Friday, August 24, 2012

Greasemonkey 1.0 Release

After more than seven years, Greasemonkey has finally grown to version 1.0.

Back in August of 2005 (almost exactly seven years ago now), Greasemonkey introduced wrappers intended to plug security holes.  As a result the common pitfalls were born.  Ever since then, in order to write a user script that would function properly in Greasemonkey, authors were required to either get lucky and not trip over one of these pitfalls, or get lucky and figure out that they exist -- and how to work around them.

As of today, all you have to know is "@grant none".  If you specify this setting in your metadata, then none of these security wrappers are put around your script. And you aren't granted access to any of the Greasemonkey APIs that a normal page wouldn't have.  Almost anything you can do in a script in the page itself should work in a "@grant none" user script.  There is still a sandbox; this isolates your variable scope from the page itself.  Without this it is extremely easy to break the page.  In order to explicitly read/write to/from the content scope, just reference properties of the window object.  (I.E. "x = 10" assigns to a variable x only in the user script's private scope.  "window.x = 10" assigns to the variable x in the content page's scope, which it can see.)


The entire list of bugs handled in this release is also available via the 1.0 milestone on GitHub. A number of issues listed there only affected Greasemonkey during the development of version 1.0, so they aren't listed as changes below.

As always, if you notice problems, it's best to log an issue at GitHub or let us know at the greasemonkey-dev mailing list (and be clear that your issues are with this version).

Enhancements since Greasemonkey 0.9.x:
  • New metadata, @grant, specifies which special APIs a user script will have access to.  Specifying @grant none means no special API access, and thus no security restrictions.  Then, everything you're used to doing in JavaScript in a web page (including but not limited to jQuery) should just work.  For legacy scripts (which have no @grant line at all), Greasemonkey will try to guess what @grant lines you should have.  See http://wiki.greasespot.net/@grant for more detail. (#1425, #1427, #1558)
  • The toolbar button is colorful (in the enabled state) on Mac OS X. (#1597)
  • The metadata @unwrap has been removed, as being unwrapped is now the default.  The wrapper will still be applied to scripts that have a "return" statement outside of any function, but this may be removed in the future, so make sure your scripts (and requires) don't do this; authors may manually add an anonymous function wrapper around the script for the exact same behavior. (#1568, #1592)
  • Scripts that @run-at document-start have a valid document object to modify, E.G. for adding <style> tags; but still before any part of the document is loaded. (#1565)
  • GM_xmlhttpRequest() accepts a timeout option.  (#1561)
  • GM_getResourceURL() works with a special protocol handler.  (This is more efficient/faster than the data: URI encoding used previously.)  For example, specify images and styles with URLs to your @resources.
  • The standard Firefox web developer console works for console.log() et al.  (#1564)
  • Automatic updates work correctly with scripts installed from userscripts.org (but still note the require secure updates setting). (#1555)
  • Require at least Firefox 14.0 (no more Firefox 3 compatibility).  (#1426, #1522)
  • Error reporting is much more consistent and obvious than in the past. (#1404, #1592)
  • The alert() workaround (see http://bugzil.la/647727) is not applied for Firefox versions that do not exhibit this bug.  (#1318, #1350)
Bug fixes since Greasemonkey 0.9.x:
  • When downloading a script not encoded in UTF-8, display an error message to the user (rather than just failing). (#1588)
  • The "show script" button in the install dialog is disabled until the download of the script file is complete. (#1586)
  • Scripts with missing or broken "==UserScript==" metadata will work.  (#1562)

Thursday, August 09, 2012

Beta: Greasemonkey Release 1.0beta7

The entire list of bugs handled (and some still pending) in this release is also available via the 1.0 milestone on GitHub. This is only a beta release so you'll need to head to the all versions page to find it.

After more than seven years, Greasemonkey is finally graduating to version 1.0!  We're taking the major version number bump as an opportunity to reconsider some big ideas.  As of right now we believe there are appropriate detections and modes to make everything continue to work as always, but we're laying the groundwork to really break backwards compatibility, perhaps in a 1.1 release.

Keep an eye on this blog for posts dedicated to more detail on these topics.  For now each is briefly mentioned in the changelog below.

We desperately want feedback on this beta release, especially from script authors.  If you are using it and notice problems of any kind or have any other feedback for us, it's best to log an issue at GitHub or mail us at greasemonkey-dev (and be clear that which version is under discussion).

Enhancements since Greasemonkey 0.9.x:
  • New metadata, @grant, specifies which special APIs a user script will have access to.  Specifying @grant none means no special API access, and thus no security restrictions.  Then, everything you're used to doing in JavaScript in a web page (including but not limited to jQuery) should just work.  For legacy scripts (which have no @grant line at all), Greasemonkey will try to guess what @grant lines you should have.  See http://wiki.greasespot.net/@grant for more detail. (#1425, #1427, #1558)
  • The metadata @unwrap has been removed, as being unwrapped is now the default.  The wrapper will still be applied to scripts that have a "return" statement outside of any function, but this may be removed in the future, so make sure your scripts (and requires) don't do this; authors may manually add an anonymous function wrapper around the script for the exact same behavior. (#1568, #1592)
  • Require at least Firefox 14.0 (no more Firefox 3 compatibility).  (#1426)
  • Scripts that @run-at document-start have a valid document object to modify, E.G. for adding style tags; but still before any part of the document is loaded. (#1565)
  • GM_xmlhttpRequest() accepts a timeout option.  (#1561)
  • GM_getResourceURL() works with a special protocol handler.  (This is more efficient/faster than the data: URI encoding used previously.)  For example, specify images and styles with URLs to your @resources.
  • The standard Firefox web developer console works for console.log() et al.  (#1564)
  • Error reporting is much more consistent and obvious than in the past. (#1404, #1592)
Bug fixes since Greasemonkey 0.9.x:
  • Scripts with missing or broken "==UserScript==" metadata will work.  (#1562)
  • The alert() workaround (see http://bugzil.la/647727) is not applied for Firefox versions that do not exhibit this bug.  (#1318, #1350)
  • When downloading a script not encoded in UTF-8, display an error message to the user (rather than just failing). (#1588)
  • The "show script" button in the install dialog is disabled until the download of the script file is complete. (#1586)

Tuesday, July 31, 2012

Greasemonkey 0.9.22 Release

The entire list of bugs handled in this release is also available via the 0.9.21 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

This release contains just one important fix:

Bug fixes:
  • Fix memory leak related to GM_registerMenuCommander. (#1578)
Update:
I bungled a bit of the release, as early commenters below note.  I also hit a bug in the Mozilla Add-ons site in the process, so this release is now called 0.9.22, and officially there is no version 0.9.21.  Sorry!

Monday, May 14, 2012

Greasemonkey 0.9.20 Release

The entire list of bugs handled in this release is also available via the 0.9.20 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

Enhancements:
  • When the toolbar is in text-only mode, the "Greasemonkey" label on the toolbar button will be striked-out when Greasemonkey is disabled. (#1544)
  • When selecting a script editor, the previous choice will be remembered and displayed. (#1546)

Bug fixes:
  • A change in 0.9.19 broke setTimeout() for a variety of cases, that has been reverted. (#1549, #1552, #1553)
  • Scripts with long names and/or file names could fail to install in Windows. (#1548)

Monday, April 23, 2012

Greasemonkey Release 0.9.19

The entire list of bugs handled in this release is also available via the 0.9.19 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

Enhancements:
  • A custom wrapper to make setTimeout() work even when Javascript is disabled. (#1209)
  • Restored the "script installed successfully" toast notification. (#1511)
  • Scripts download more incrementally; the install dialog should appear as soon as the script metadata has been downloaded, not after the entire script is downloaded.  (#1523)
Bug fixes:
  • Specifying a script editor in a non-ASCII folder will work (Firefox 4+ only). (#1173)
  • Scripts installed while the Add-Ons Manager is open will show their icon. (#1535)
Plus a variety of minor code cleanups and enhancements behind the scenes.

Tuesday, February 28, 2012

Greasemonkey 0.9.18 Release

The entire list of bugs handled in this release is also available via the 0.9.18 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

Enhancements:
Bug fixes:
  • Add-on Manager shows correct data when re-installing (e.g. to update) a script. (#1476)
  • Re-installed scripts are put into the same directory as the original. (#1515)
  • The matches property of GM_info is now a list of (pattern) strings. (#1516)

Automatic script updates come to Greasemonkey

In the 0.9.18 release, Greasemonkey is now checking for, and installing, updated versions of user scripts by default.  This post is intended as a primer for how this new functionality works, both for users and for script authors.


The Greasemonkey Options dialog now includes these settings to control automatic update checking and installation. By default updates will be checked for every seven days, and automatically installed when found.  The download location must be secure (https) by default.  And it should just work!

If you know there's an update, you can open the Add-ons manager, right click on a User Script, and choose "Find Updates".  This will check immediately, even if a scheduled check has happened more recently than seven days ago.*

*You may need to clear your browser cache, if an old version of the script was downloaded recently.

Script Authors
Greasemonkey supports a number of new metadata directives to support updates: @downloadURL, @updateURL and (more than before) @version.

The @updateURL will be accessed when checking for the update.  This can be a ".meta.js" format like userscripts.org produces, with only the metadata.  The @version defined here will be checked to the install version.  It does not need to be hosted on https to be checked by default.

Sidebar: for userscripts.org, the updateURL is automatically set to the .meta.js corresponding to the script, and passed through the Coral Content Distribution Network (see why).

The @downloadURL is where the update will be downloaded from, when found.  This is most useful to guarantee that updates come from a secure (https) location, so that they will be installed by default.

If @updateURL or @downloadURL are not provided, the URL that the script was downloaded from is used instead.  If the @downloadURL is not provided and the install URL is not known, updates will never be applied.

Finally the @version directive controls what is considered an update.  Read about the (Mozilla) toolkit version format to learn exactly what value is greater than what, and what formats are valid.

It's also worth pointing out that the recently added GM_info API can be used to check if Greasemonkey will ever try to apply updates (e.g. because the user has turned it off, or the URL is insecure).

Finally, if you want to make sure that Greasemonkey will never update your script, it can be accomplished by providing an invalid @updateURL (like "about:blank") which will never return a newer version.

Questions?
Please bring any questions or comments to us at the greasemonkey-users discussion list.

Saturday, February 11, 2012

Greasemonkey 0.9.17 Release

Whoops, there was a problem with 0.9.16 yesterday, so here's a quick patch.

Bug fixes:
  • Error: "aForced is not defined".  (#1517)

Friday, February 10, 2012

Greasemonkey 0.9.16 Release

The entire list of bugs handled in this release is also available via the 0.9.16 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

Enhancements:
  • Expose information (including Greasemonkey version) to user scripts via GM_info. (#1452; also see #1512)
  • Track the install time of scripts.  (This is designed to better support automatic updates for scripts ... still coming soon.)  (#1513)
Bug fixes:
  • Editing script from the "New User Script" feature, to change any remote dependency (@icon, @require, @resource), could the script to malfunction. (#1504)
  • Enabling/disabling scripts from the status bar menu (Firefox 3 only). (#1506)
  • Incompatibility with GreaseFire.  (#1507)
  • Failures during "Check for Updates" from the Add-on manager. (#1509)

Wednesday, January 25, 2012

Greasemonkey 0.9.15 Release

The entire list of bugs handled in this release is also available via the 0.9.15 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

This release was hurried, to resolve a few serious bugs introduced in 0.9.14. A few other bugs were also fixed.

Bug fixes:
  • Editing an installed script to change any remote dependency (@icon, @require, @resource) could cause one or many scripts to be deleted. (#1466, #1502)
  • Certain @requires can break a script, due to javascript semicolon insertion rules.  (#1491)
  • Toggling the enabled state of a script via the main (Tools > Greasemonkey) menu failed on Mac.  (#1496)
  • Installing a script from local disk failed in 0.9.14.  (#1501)

Friday, January 20, 2012

Greasemonkey 0.9.14 Release

The entire list of bugs handled in this release is also available via the 0.9.14 milestone on GitHub. Note that as always it takes some time for Mozilla to review the new version, but it's available on the all versions page immediately.

If you are using it and notice problems, it's best to log an issue or let us know at greasemonkey-dev (and be clear that it's with this version).

Enhancements:
  • For new script installs, and installed scripts' updates (still not enabled by default) there is a progress meter for the download. (#1419)
Bug fixes:
  • Revert the changes to GM_xmlhttpRequest() in 0.9.13 (which were supposed to have no effect, but created a subtle bug). (#1472)
  • Guarantee that we do not create a specific kind of memory leak.  (#1482)